[03:09] <lifeless> wow
[03:09] <lifeless> enough recipe mail today?
[03:57] <AfC> lifeless: I know about bzr builddeb's import-upstream, but I heard you mention 'import-tar' (sic) once. Is that something different?
[03:58] <lifeless> yu[p
[04:06] <idnar> so I'm trying to push a pipeline to somewhere else with bzr sync-pipeline
[04:06] <idnar> but "bzr sync-pipeline bzr+ssh://lorien/path/to/dir" gives me "bzr: ERROR: Pipeline has no pipe named "dir"."
[04:06] <idnar> I guess I'm doing it wrong?
[04:07] <AuroraBorealis> whats a pipeline? o.o
[04:11] <idnar> http://wiki.bazaar.canonical.com/BzrPipeline
[04:18] <idnar> mmm, okay, did bzr init on the remote location
[04:18] <idnar> and now sync-pipeline seems to have worked
[04:19] <AuroraBorealis> yay
[04:29] <idnar> hmm, spoke too soon, that made a complete mess
[04:29] <AuroraBorealis> i dont know much about pipelines =/
[04:39] <idnar> okay clearly I don't understand how to use sync-pipeline :/
[04:40] <AuroraBorealis> someone more knowledgable can probably help
[04:40] <AuroraBorealis> although they might be in bed o.o
[04:40] <idnar> I should be in bed too, it's 06:40 here
[04:40] <AuroraBorealis> lol
[04:40] <AuroraBorealis> bed
[06:02] <vila> hi guys !
[06:02] <vila> meh, hi girls and guys !
[06:19]  * idnar attempts to learn bzr-colo
[06:19] <idnar> hey vila
[06:23]  * fullermd is shocked at the discrimination against neuters...
[06:45] <vila> fullermd: :)
[06:58] <jelmer> hi *
[06:58] <mgz> morning all
[06:59] <mgz> meeting now or in an hour?
[06:59] <poolie> hi jam, jelmer, mgz
[06:59] <poolie> good question
[06:59]  * jelmer was wondering about that too :)
[06:59] <vila> hey .
[06:59] <poolie> according to my mail it would be in an hour
[06:59] <jam> I'm around, but officially we were keeping the UTC time
[06:59] <poolie> but, if everyone's here, we could go now
[07:00] <vila> wfm
[07:02] <jelmer> wfm, although I still have to finish the mumble setup dance..
[07:03] <vila> jelmer: I can see that ;)
[07:03] <jelmer> hah, it works :)
[07:03] <mgz> is Riddell on yet? he's an hour later with me
[07:07] <vila> mgz: good point, should we just wait then ?
[07:09] <idnar> Branches are also hidden if they have the option "bzr.branch.status" set to
[07:09] <idnar> "Hidden", "Merged" or "Abandoned".
[07:09] <idnar> how does bzr.branch.status get set?
[07:17] <poolie> vila, i don't see riddell yet so we should wait
[07:17] <poolie> idnar, i guess you can set it through 'bzr config bzr.branch.status=Merged', and i think explorer (?) has a thing to set it
[07:17] <idnar> ah okay, so no way to get it from launchpad or whatever
[07:22] <vila> glitch in the matrix, both mgz and wgz are online
[07:24] <mgz> ha ha, no more.
[07:24] <AfC> jelmer: ping (low priority, just to chat when you get a moment)
[07:29] <poolie> idnar, no, not hooked up
[07:39] <jelmer> AfC: hi
[07:41] <AfC> jelmer: yo
[07:42] <AfC> jelmer: so, I tried, a number of ways, to bzr branch "that tree". They all failed, until I drove it down to
[07:42] <AfC> $ bzr branch -r 1 foreign import
[07:43] <AfC> admittedly it didn't help there is only 1.5 GB of physical memory on that machine, but they all got wedged at ~3.2 GB virtual memory and, interestingly, 315 minutes of CPU time.
[07:43] <AfC> at that point, it was endless swapping.
[07:45] <AfC> I haven't tried it against the tree at the remote server; that's next, but I'm getting closer to feeling I'm going to have to give up. Now that I've got revno 1 it might get a bit better to pull 1 or 10 or 100 revisions at a time.
[07:45] <AfC> end
[07:46] <jelmer> AfC: What kind of foreign tree is this with?
[07:46] <jelmer> AfC: and what versions?
[07:46] <AfC> jelmer: git
[07:46] <AfC> jelmer: daily
[07:47] <jelmer> AfC: hmm, that's odd
[07:48] <jelmer> AfC: the launchpad importers probably have about the same resources and can handle the linux kernel
[07:49]  * jelmer tries locally
[07:54] <jelmer> jam: hi
[07:54] <jam> hi jelmer
[07:54] <jelmer> jam: Goeiesmorgens deze morgen!
[07:54] <jelmer> jam: I'm trying to figure out something with stacking, perhaps you have an idea
[07:54] <jam> stacking doesn't work? :)
[07:55] <jam> sure, go ahead
[07:55] <jelmer> jam: in some situations :)
[07:56] <jelmer> jam: In short, I'm finding that if I have some revisions in a stacked-on repository and then try to fetch some ancestors of that into the stacked repository things go boom.
[07:56] <AfC> jelmer: [it turns out that I was, in effect, duplicated what vcs-import already did, since `bzr missing --line --mine` reported the same revs. But that's one of the things I needed to establish before using launchpad's branch]
[07:57] <AfC> duplicating*
[07:57] <jelmer> AfC: yeah, the imports should be deterministic
[07:57] <jelmer> jam: I'm getting an exception from pack_repo during commit_write_group() saying one of the parent texts was missing
[07:58] <AfC> jelmer: In any event, I'm also going to have a go at `bzr import-upstream` across the range of trees that I'm interested in
[07:58] <jelmer> AfC: import-stream?
[07:58] <AfC> bzr-builddeb's import-upstream ?
[07:59] <jam> jelmer: do you have a traceback I can peek at?
[07:59] <jam> My immediate thought is that fetch doesn't work very well in this situation, because revision discovery will think you already have the data
[07:59] <jelmer> jam: http://pastebin.ubuntu.com/702120/
[08:00] <jelmer> jam: fwiw this is with foreign branches
[08:00] <jelmer> AfC: Do you mean in addition to importing from Git? Since they do very different things.
[08:01] <jam> jelmer: from that traceback it looks like all of the logic of what needs to be transmitted is in bzr-svn (the layers of 'fetch' are all svn, just the 'commit_write_group' is bzr)
[08:01] <AfC> jelmer: in addition (separate branch family) yes
[08:01] <jam> it looks like you fetched the revision texts but failed to fetch the associated file content
[08:02] <AfC> jelmer: lifeless was telling me that I should also look at `import-tar` which is something I'm not familiar with. Not sure what plugin its in, even. But when I find it, I'll try that too
[08:02] <jelmer> AfC: Do you mean "bzr import" from bzrtools perhaps?
[08:03] <AfC> jelmer: ah, maybe. Don't [normally] have bzrtools installed.
[08:03]  * AfC wonders whether I'll have more luck with bzr-builddeb or bzrtools's take on this
[08:04] <jelmer> jam: The file content is in the stacked-on repository
[08:05] <jam> jelmer: just getting static from you
[08:06] <jam> jelmer: so the immediate thought is that the "do you have references filled in" is only checking the newly created pack files.
[08:18] <jelmer> jam: I think that's the crux of the problem. What does filling in the references mean exactly?
[08:33] <jam> jelmer: looking at the code it sure looks like it is properly checking everything that is in the stacked repo (so not the fallback, but everything in the repository)
[08:34] <jam> 'filling in the references', if you have a revision it needs an inventory, and it needs all referenced file texts
[08:35] <jelmer> jam: ah, hmm. and I shouldn't rely on those being present in a stacked-on repository?
[08:35] <jam> (well all referenced file texts that aren't in the parent revisions, etc)
[08:36] <jelmer> That makes sense, and I'm not doing that at the moment.
[08:36] <jam> jelmer: well, you said that they were, but Bazaar is saying they aren't
[08:36] <jam> jelmer: ah, you mean they are in the fallback?
[08:36] <jelmer> jam: yes
[08:36] <jam> no, that is not sufficient
[08:36] <jam> If a stacked repo has revision X, it needs to have the texts introduced in X
[08:36] <jam> otherwise it cannot create a stream containing revision X
[08:37] <jam> without talking to the fallback
[08:37] <jam> which we require
[08:37] <jelmer> but what about texts that weren't introduced in X but are present in X?
[08:37] <jam> (remote smart server does not have access to its fallback)
[08:37] <jam> jelmer: if you have rev A parent of rev B, and you have (file_1, A) you don't have to have that content in a stacked repo with just B
[08:37] <jam> *if* you have the inventory for A
[08:38] <jam> so that we can tell whether (file_1, A) was present in the parent
[08:38] <jam> so what you need is set(present_revision_texts) - set(parent_revision_texts)
[08:46] <jelmer> jam: So I should fetch the rev A inventory into the stacked repository, even if it's already present in the stacked-on repository?
[08:50] <poolie> Riddell, could you clean up and post those notes?
[08:50] <Riddell> poolie: can do
[08:50] <poolie> ta
[08:50] <Riddell> poolie: I think I should take a day off bzr sometime this week to check up on Kubuntu, it's their release week
[08:51] <poolie> oh good diea
[08:51] <poolie> *idea
[08:51] <poolie> or even more if necessary
[08:54] <jam> jelmer: yes
[08:57] <jelmer> jam: ok, that makes sense
[08:57] <jam> jelmer: so if you want to put rev B in a stacked repository, you need to have inventory of A, and all of the texts that are in B that aren't in A
[08:58] <jam> and B's inventory, of course
[09:23] <poolie> mgz, vila, so https://code.launchpad.net/~jameinel/bzr/drop-idle-connections-824797/+merge/75348
[10:11] <jelmer> jam: What's the easiest way of doing so (fetching an inventory into a repository if it isn't present yet, while excluding any stacked-on repos)?
[10:17] <jelmer> vila: sorry, I missed that. What will I disagree with?
[10:17] <vila> jelmer: making bzrlib.intialize() mandatory
[10:18] <jelmer> ah
[10:18] <jelmer> yes (though I wouldn't mind make it implicit and warn if it wasn't explicitly called)
[10:19] <jelmer> Jelmer's bug? There's just one ? :P
[10:19] <jelmer> (I lost my unity panel so I can no longer unmute :P)
[10:23] <mgz> bug 863401 jelmer if you're not already there
[10:30] <vila> Riddell: thanks for sending the standup notes !
[10:31] <Riddell> how can I see collision merge proposals?  launchpad times out on https://code.launchpad.net/~ubuntu-branches/+activereviews
[10:31] <jelmer> poolie: it's calm and relaxing to have some typing going on in the background.. :)
[10:45] <poolie> jelmer :)
[10:46] <poolie> like those CDs of sea sounds
[10:47] <jelmer> heh, indeed
[10:47] <poolie> jelmer, it's kind of nice, maybe we should stay on mumble during the evenings
[10:47] <poolie> especially if we either get noise suppression right or ptt
[10:48] <jelmer> poolie: yeah, it is. I put getting a new headset on my todo list.
[10:49] <mgz> likewise.
[10:50] <mgz> ooh, fancy oops pages with my new team membership
[10:52] <poolie> oh, tracebacks
[10:52] <poolie> "fix me!"
[10:52] <poolie> https://bugs.launchpad.net/launchpad/+bug/866100
[10:59] <nigelb> poolie: Is that the bug you just "fixed"? :D
[11:00] <nigelb> ah, exposed as part of the fixing
[11:10] <poolie> nigelb, now you can get to that page but it may not render :/
[11:10] <nigelb> poolie: Ouch!
[11:11] <nigelb> poolie: why does that happe? I thought search was fast.
[11:11] <nigelb> Or at least more efficient.
[11:12] <nigelb> oh. I see you're talking to stuart already :D
[11:22] <poolie> jam, i'd appreciate if you can try to help the ohloh guy some more
[11:22] <poolie> with his memory leak
[11:30] <jam> poolie: sure, I'm guessing it is us just caching more of the indexes, but I'll try to poke at it with him
[11:31] <mgz> hm, I wonder if what I was looking at yesterday was relevent then
[11:31] <mgz> just doing switch created 5 repository instances, 4 of which persisted through the operation, each with five LRUSizeCache objects with a 50MB limit
[11:32] <mgz> that's nearly a gig of potential cache, were they all doing stuff
[11:32] <mgz> (in practice only the texts cache is *that* large)
[11:33] <mgz> but if they're doing things with repos and bzr is giving them new caches each time and the old ones are being hung on to...
[11:41] <vila> mgz: last warning from PP, if you don't land these proposals, I will ;)
[11:45] <vila> mgz: more seriously, you proposed a fix for http://bugs.python.org/issue12544 what happened ?
[11:48] <mgz> it landed, but did onieric ever move from the problem python revision?
[11:49] <mgz> and yes yes, I'll land 'em... after lunch
[11:50] <vila> mgz: Bon appétit !
[11:52] <jam> mgz: 50*4 = 200, not quite 1GB
[11:53] <jam> mgz: also, we tend to have Repository objects that live a bit long because of reference cycles.
[11:53] <jam> but it would be good to understand why we would have 5 repos opened
[11:53] <fullermd> "each with 5..."
[11:53] <jam> fullermd: 4 persisted
[11:53] <jam> ah
[11:53] <jam> 5*5
[11:53] <jam> sure
[11:53] <vila> mgz: yup, oneiric seems to have your patch too (or its moral equivalent:  self._type_equality_funcs = {})
[11:55] <mgz> okay, just one more branch to bother the rm before lunch
[11:56] <mgz> ...dammit, lynx why won't you play nice with launchpad
[11:57] <mgz> s/rm/patch pilot/
[11:57] <mgz> jam: each time control_dir.anything happens, you get a new repo
[11:58] <jam> mgz: there are some cases where we allow passing in something new
[11:58] <jam> I don't remembe rexactly where
[11:59] <vila> mgz: they happen to be the same this week ;)
[12:02] <jam> mgz: were bugs #866107 and bug #866111 supposed to be assigned to you?
[12:05] <mgz> ...I'll take the first one
[12:05] <mgz> the second one I find a little more scary
[12:06] <mgz> okay, patch pilot bothered, lunch must be had.
[12:09] <vila> mgz: approved
[12:20] <jam> mgz: I just didn't know whether you were only filing them, or they were supposed to be assigned to you
[12:20] <jam> not a big deal
[12:26] <jelmer> jam: what's the easiest way to make sure inventory X is present in a repository itself (rather than any of its stacked repositories) ?
[12:26] <jam> jelmer: X in repository.inventories._index.get_parent_map([X])
[12:26] <jam> or you can use the "inventories.no_fallbacks().get_parent_map()"
[12:27] <jelmer> jam: Ah, and just call repo.add_inventory() if it's missing?
[12:28] <jam> jelmer: generally i would add it as part of the record stream, but I'm not sure how it works with bzr-svn
[12:29] <jam> doing add_inventory is going to be a serialization/deserialization overhead
[12:29] <jelmer> jam: ah
[12:29] <jam> maybe add_inventory_by_delta?
[12:29] <jelmer> jam: I'm already using add_inventory_by_delta to add the revision I'm fetching
[12:29] <jam> jelmer: then you can chain that to add the parent inventory
[12:29] <jam> I believe that add_inventory_by_delta can use any basis
[12:29] <jam> it doesn't have to be a direct parent/child/sibling
[12:30] <jelmer> jam: This is about making sure the basis is in the repo I'm calling .add_inventory_by_delta on
[12:30] <jam> jelmer: note that delta basis can also be 'null', but that is the same as doing just raw add_inventory()
[12:30] <jam> jelmer: so you are adding the inventory for B, what is the basis for that delta?
[12:31] <jelmer> jam: A, but A could be in my target repository or one of A's stacked repositories
[12:31] <jelmer> jam: A, but A could be in my target repository or one of A's fallback repositories
[12:33] <jelmer> sorry, not sure what's up with my typing today
[12:33] <jelmer> jam: A, but A could be in my target repository or one of my target repository's fallback repositories
[12:34] <jam> mgz: do you have 'feed-pqm' set up from hydrazine? I'm just going through and sending your approved patches to pqm
[12:34] <jam> hopefully not stepping on toes
[12:34] <jam> but I'm there already
[12:35] <jam> vila: it says your 863401-library-state has been sent. Did it bounce?
[12:35] <jam> I don't see anything in pqm right now
[12:38] <vila> look again ?
[12:43] <jam> vila: I see 2 that I submitted
[12:43] <jam> neither is yours
[12:44] <jam> vila: maybe it bounced but you didn't get the reply?
[12:44] <jam> want me to submit it?
[12:45] <vila> looks landed to me
[12:48] <jelmer> jam: Please have another look at https://code.launchpad.net/~jelmer/bzr/more-foreign-tests-fixes-7/+merge/76776 when you have a moment
[12:56] <jam> vila: it was still in "sent to pqm" on feed-pqm, maybe it just hadn't updated yte
[12:56] <jam> yet
[12:56] <jam> yep, looks like
[12:56] <jam> I just hit it inbetween pqm finishing it, and launchpad noticing
[12:57] <mgz> hm, the release notes file could do with some sorting out
[12:57] <mgz> maybe I shouldn't try and sneak in news pqm lands the next branch
[12:57] <mgz> +before
[13:11] <jam> mgz: pqm only takes about 30min, you can just put up a news fix
[13:14] <mgz> ah, missing the day of slow pqm...
[13:23] <mgz> ah, I see the ohloh thing now, twas a question not a bug
[13:25] <mgz> if he's running cmd_cat repeatedly, he's going to be getting a new cache each time, no jam?
[13:25] <jam> mgz: he isn't
[13:25] <jam> he changed it
[13:25] <jam> if you read the follow up
[13:25] <jam> but yes, the original suffered from stuff like that
[13:26] <mgz> yeah, I'm behind, getting there...
[13:34] <mgz> hm, landing the server hangs branch and the test cleanup branch so close to each other may have not been a good idea
[13:48] <jelmer> vila: more-foreign-tests-fixes-{7,9} are both ready for review
[13:49] <vila> jelmer: on them
[13:54] <vila> jelmer: balloon ? :)
[13:55] <vila> jelmer: is that some kind of crocodile to check the reviewer actually read your proposal ? ;-P
[13:55] <jelmer> vila: that test was already there, I just moved it :)
[13:55] <vila> oh, ok, not there yet then ;)
[13:55] <vila> ha right, just after
[14:00] <vila> jelmer: -9 approved
[14:03] <mgz> why so forceful vila?
[14:04] <vila> hehe, took me two readings :)
[14:04] <vila> jelmer: -7 approved
[14:04] <jelmer> vila: merci!
[14:30] <jam> jelmer: your foreign-tests-7 has 3 errors
[14:37] <jelmer> jam: thanks, having a look now..
[14:49] <jelmer> hmm, the other one also has 3 failures
[15:10] <mgz> the pqm failure for my cleanup testcases branch is the stuff of nightmares
[15:11] <mgz> there's one failure. it's on *one* of the three iterations of test_random_seed and the other two pass. the failure output make no sense at all.
[15:24] <vila> mgz: you ignored the expected failures right ?
[15:26] <mgz> yup, though they still confused me at first
[15:27] <mgz> found one actual issue with the code, the way tests get counted needs sorting out after adopting Robert's method of injecting extra testcases
[15:35] <vila> mgz: where is this test ?
[15:36] <vila> mgz: oh, the one about selftest itself ?
[15:37] <mgz> I'll paste in the mp.
[15:38] <vila> k
[15:45] <mgz> posted.
[16:00] <mgz> okay, result.shouldStop is getting set somehow...
[16:00] <mgz> which still doesn't really explain the weirdness, but needs afixing
[16:11] <vila> ubuntu is making fun of me: The program 'selftest' is currently not installed.  You can install it by typing:
[16:11] <vila> sudo apt-get install yagiuda
[16:12] <vila> mgz: can' reproduce locally, any hint in stderr ?
[16:14] <mgz> nope. straight up unrepoable.
[16:15] <mgz> but I'm fixing this other bug, and may do one more tweak before trying PQM again
[16:15] <vila> get rid of it, file a bug if you wish unless you're really using it to trigger more related issues, almost nobody use random
[16:16] <vila> but in any case, it doesn't sound worth delaying the bulk of the patch just for that
[16:18] <mgz> okay, got this one.
[16:21] <mgz> does PQM fork vila?
[16:27] <vila> no
[16:27] <vila> we'd like to eventually
[16:28] <vila> ... but we recently went from several hours to 30 mins, we need to recover a bit from the shock
[16:30]  * vila EODing
[16:30] <vila> almost :)
[16:31] <jonnor> Hi. I have changes in my working tree, however I don't want to commit them to the branch I'm currently on.
[16:31] <jonnor> However, bzr switch will not let me switch with "unmerged changes" and bzr shelf --all says "bzr: ERROR: Tree transform is malformed [('missing parent', 'new-8'), ('missing parent', 'new-2'), ('missing parent', 'new-3')]"
[16:31] <jonnor> What to do?
[16:32] <briandealwis> jonnor: see the shelve command
[16:32] <jonnor> briandealwis: shelve is what I tried, and failed as show above
[16:33] <briandealwis> oops sorry jonnor — missed that :/
[16:33] <briandealwis> actually, I've seen that before too, and neglected to file a bug
[16:33] <jonnor> my changes are actually from an uncommitted commit if that matters
[16:35] <vila> jonnor: bzr version ?
[16:35] <jonnor> vila: Bazaar (bzr) 2.4.1
[16:36] <vila> >-/
[16:36] <vila> jonnor: please file a bug
[16:38] <vila> jonnor: 'shelf' was a typo right, you really meant 'shelve' (there was a shelf command long ago in bzrtools)
[16:39] <jonnor> vila: yes
[16:39] <jonnor> I have no idea on how to reproduce this issue though
[16:43] <vila> jonnor: file a bug anyway, adding the relevant part of your .bzr.log file will give some data
[16:51] <jonnor> vila: ok
[16:52] <jonnor> Is it expected that bzr commit after an attempted merge does not have any metadata like the commit message of the commit that failed to merge?
[16:57] <jonnor> it seems probable that https://bugs.launchpad.net/bzr/+bug/611739 is the bug I experienced
[17:02] <mgz> blast, didn't get to reviewing benoit's branch today.
[17:03] <mgz> ah well, tomorrow
[17:19] <vila> mgz: Just crossed my mind, you know pqm is running old versions of testtools and subunit right ?
[17:20] <aidos> hello all. how do you run the tests (or better, a specific test) from the bzrlib testsuite ?
[17:21] <vila> aidos: bzr selftest -s bzrlib.tests.blackbox.test_push will run only the tests whose name starts with bzrlib.tests.blackbox.test_push
[17:22] <vila> aidos: some short prefixes are available: bt -> bzrlib.tests, bb -> bzrlib.blackbox, bp -> bzrlib.plugins
[17:23] <aidos> vila: thanks. but is that going to run the testsuite from my installed bzr version, or from the branch I got from launchpad ?
[17:24] <aidos> vila: it seems strange that I need to call bzr to run tests, especially for bzrlib where i just want to add a test to some osutils.py functions
[17:28] <vila> aidos: ./bzr will run from sources, but you probably want to run 'make' before to build the extensions
[17:37] <aidos> vila: thanks, now my test fails as expected, now onto the bugfix :)
[19:10] <caravel> Hellooooo there :) Is there any list of apps (eg wikis) that can *sit* on a DSCM like Bazaar (using it as underlaying storage) ? Myself in particular, I'm looking for a collaborative task manager ^^
[19:17] <beuno> caravel, there's wikkid
[19:17] <beuno> which is a wiki engine backed-up by bzr
[19:22] <caravel> beuno: yes thanks, I found this one indeed -- somehow I didn't find any ref on it at bazaar website (google helped me find it).
[19:22] <caravel> Besides, it doesn't advertise to be stable yet.
[19:22] <caravel> Are you people aware of more tapps of this knd, especially oriented to manage *tasks* ?
[19:23] <caravel> *apps
[19:23] <caravel> *kind (etc., sorry typing too fast)
[19:23] <james_w> ikiwiki too
[19:25] <caravel> james_w: hey thanks, I had "lost" that one ^^
[19:28] <caravel> here we go, I'm lost in its plugin list again :=
[19:30] <caravel> would you reckon a wiki could be turned to an efficient-enough task manager somehow ? ^^
[19:34] <caravel> http://ikiwiki.info/todo/interactive_todo_lists/
[19:58] <jonnor> caravel: I'd recommend an issue tracker instead
[19:59] <jonnor> and I do not see any reason to care about whether the underlying storage tech on a dscm
[20:12] <caravel> jonnor: well, I do. :) To start with, stricly speaking about SCM, what are your reasons to use a DSCM ?
[20:18] <jonnor> caravel: so I have full access to the history, and can add to the history without having to make these changes public or be connected to a central location
[20:19] <caravel> jonnor: well, I have the same requirements for managing tasks, simply ^^
[20:20] <caravel> plus the will to push my changes, obviouly
[20:21] <jonnor> caravel: how will conflicts be resolved?
[20:26] <caravel> jonnor: how do you solve conflicts with bzr, rsync, iFolders (...) or these 2 wikis running on top of a DSCM ? Well, you need conflifts brought to your attention, access to history, then manual resolution. How is this different to files ? A task manager that would store each task and each category as a single file on disk, would suit I think. But I didn't find any ^^
[20:29] <jonnor> caravel: it is just something you need to thing about when you decide on the solution. If it is OK for your users having to resolve conflicts line-by-line in text files, then something on top of dvcs might work ok
[21:41] <ccxCZ> icalendar files are pretty readable
[21:43] <ccxCZ> I used conics for todos for a while, replicated with bzr, I even forked it to add yaml export/import for easy editing
[22:07] <poolie> hi all
[22:07] <caravel> ccxCZ: thanks for your hints, will investigate
[22:09] <ccxCZ> for issue tracker I find roundup interesting, but that's mail-based mostly
[22:11] <wgz> hey poolie.
[22:16] <poolie> hi there
[22:18] <wgz> what's the current contributor agreement arrangement?
[22:19] <wgz> I got Florian to do a more comprehensive version of his fix, hopefully that doesn't mean he now needs to print a pdf and find a scanner
[22:19] <poolie> wgz, just an email with an attachment is enoguh
[22:20] <poolie> the page is wrong and will soon be updated, if it's not already
[22:20] <wgz> that's a relief.
[22:24] <poolie> yes
[22:37] <jelmer> 'morning poolie, ɯgz
[22:38] <Riddell> poolie: how do I find merge proposals filed by udd importer?
[22:38] <wgz> ehe jelmer, I'm not sure freenode would let me have that
[22:39] <poolie> Riddell, funny you should ask, i was just adding that to the bug
[22:39] <poolie> it even doesn't always time out
[22:40] <Riddell> I tried various likely pages under ~ubuntu-branches and they all timed out
[22:40] <poolie> https://code.launchpad.net/~ubuntu-branches/+activereviews does seem to work for me at the moment
[22:40] <poolie> it's a quiet time of day for lp
[22:42] <Riddell> Timeout error here, a curious case of launchpad working better for australia than for britain
[22:50] <poolie> hit reload a few times :/
[22:50] <wgz> urk, there's lots of fallout from my commit message change in bzr-builddeb jelmer?
[22:50] <jelmer> wgz: oh?
[22:51] <wgz> I'm looking at bug 865753 and bug 867808 and wondering if they're running versions with that change
[22:51] <jelmer> Riddell: with the number of ~canonical-bazaar staff folks around at midnight UTC it doesn't quite seem like quiet time ;)
[22:52] <poolie> http://sp.reddit.com/heavy-mallet.gif
[22:53] <jelmer> ubot5: your change is only in bzr-builddeb 2.7.9
[22:53] <jelmer> wgz: your change is only in bzr-builddeb 2.7.9
[22:53]  * wgz is a bot too, the real mgz is sensible and already asleep so he can get up on time tomorrow
[22:54] <jelmer> bug 86708 is with 2.7.0, so it shouldn't be relevant to your change
[22:54] <jelmer> perhaps it's even fixed by it
[22:54] <jelmer> wgz: the other bug doesn't seem related to your fix either, apart from being a unicode issue too
[22:55] <wgz> hm from the debian report, that first is different indeed.
[22:55] <wgz> and maybe I'm just being paranoid about the second.
[22:55] <jelmer> wgz: your nickname is really annoying, xchat keeps suggesting "wgrant" :)
[22:56] <jelmer> wgz: see the BzrPlugins.txt attached on the second
[22:56] <wgz> ah yes, 0 is not 9. woho!
[22:59] <vila> . o O (No wonder I can't sleep, they are all up too)
[23:08] <jelmer> whoa :)
[23:16]  * Riddell offers vila some coffee