lifeless | wow | 03:09 |
---|---|---|
lifeless | enough recipe mail today? | 03:09 |
AfC | lifeless: I know about bzr builddeb's import-upstream, but I heard you mention 'import-tar' (sic) once. Is that something different? | 03:57 |
lifeless | yu[p | 03:58 |
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:06 |
AuroraBorealis | whats a pipeline? o.o | 04:07 |
idnar | http://wiki.bazaar.canonical.com/BzrPipeline | 04:11 |
idnar | mmm, okay, did bzr init on the remote location | 04:18 |
idnar | and now sync-pipeline seems to have worked | 04:18 |
AuroraBorealis | yay | 04:19 |
idnar | hmm, spoke too soon, that made a complete mess | 04:29 |
AuroraBorealis | i dont know much about pipelines =/ | 04:29 |
idnar | okay clearly I don't understand how to use sync-pipeline :/ | 04:39 |
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 | 04:40 |
vila | hi guys ! | 06:02 |
vila | meh, hi girls and guys ! | 06:02 |
* idnar attempts to learn bzr-colo | 06:19 | |
idnar | hey vila | 06:19 |
* fullermd is shocked at the discrimination against neuters... | 06:23 | |
vila | fullermd: :) | 06:45 |
jelmer | hi * | 06:58 |
mgz | morning all | 06:58 |
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 | 06:59 |
vila | wfm | 07:00 |
jelmer | wfm, although I still have to finish the mumble setup dance.. | 07:02 |
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:03 |
vila | mgz: good point, should we just wait then ? | 07:07 |
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:09 |
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:17 |
vila | glitch in the matrix, both mgz and wgz are online | 07:22 |
mgz | ha ha, no more. | 07:24 |
AfC | jelmer: ping (low priority, just to chat when you get a moment) | 07:24 |
poolie | idnar, no, not hooked up | 07:29 |
=== gerard_1 is now known as gerard_ | ||
jelmer | AfC: hi | 07:39 |
AfC | jelmer: yo | 07:41 |
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:42 |
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:43 |
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:45 |
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:46 |
jelmer | AfC: hmm, that's odd | 07:47 |
jelmer | AfC: the launchpad importers probably have about the same resources and can handle the linux kernel | 07:48 |
* jelmer tries locally | 07:49 | |
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:54 |
jam | sure, go ahead | 07:55 |
jelmer | jam: in some situations :) | 07:55 |
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 |
=== mrevell_ is now known as mrevell | ||
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:56 |
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:57 |
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:58 |
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/ | 07:59 |
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:00 |
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:01 |
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:02 |
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:03 | |
jelmer | jam: The file content is in the stacked-on repository | 08:04 |
jam | jelmer: just getting static from you | 08:05 |
jam | jelmer: so the immediate thought is that the "do you have references filled in" is only checking the newly created pack files. | 08:06 |
jelmer | jam: I think that's the crux of the problem. What does filling in the references mean exactly? | 08:18 |
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:33 |
jam | 'filling in the references', if you have a revision it needs an inventory, and it needs all referenced file texts | 08:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:46 |
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:50 |
poolie | oh good diea | 08:51 |
poolie | *idea | 08:51 |
poolie | or even more if necessary | 08:51 |
jam | jelmer: yes | 08:54 |
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:57 |
jam | and B's inventory, of course | 08:58 |
poolie | mgz, vila, so https://code.launchpad.net/~jameinel/bzr/drop-idle-connections-824797/+merge/75348 | 09:23 |
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:11 |
jelmer | vila: sorry, I missed that. What will I disagree with? | 10:17 |
vila | jelmer: making bzrlib.intialize() mandatory | 10:17 |
jelmer | ah | 10:18 |
jelmer | yes (though I wouldn't mind make it implicit and warn if it wasn't explicitly called) | 10:18 |
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:19 |
mgz | bug 863401 jelmer if you're not already there | 10:23 |
ubot5 | Launchpad bug 863401 in Bazaar "library state now requires explicit initialization" [Critical,In progress] https://launchpad.net/bugs/863401 | 10:23 |
vila | Riddell: thanks for sending the standup notes ! | 10:30 |
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:31 |
poolie | jelmer :) | 10:45 |
poolie | like those CDs of sea sounds | 10:46 |
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:47 |
jelmer | poolie: yeah, it is. I put getting a new headset on my todo list. | 10:48 |
mgz | likewise. | 10:49 |
mgz | ooh, fancy oops pages with my new team membership | 10:50 |
poolie | oh, tracebacks | 10:52 |
poolie | "fix me!" | 10:52 |
poolie | https://bugs.launchpad.net/launchpad/+bug/866100 | 10:52 |
ubot5 | Ubuntu bug 866100 in Launchpad itself "bug search with affects_me=on times out" [Critical,Triaged] | 10:52 |
nigelb | poolie: Is that the bug you just "fixed"? :D | 10:59 |
nigelb | ah, exposed as part of the fixing | 11:00 |
=== yofel_ is now known as yofel | ||
poolie | nigelb, now you can get to that page but it may not render :/ | 11:10 |
nigelb | poolie: Ouch! | 11:10 |
nigelb | poolie: why does that happe? I thought search was fast. | 11:11 |
nigelb | Or at least more efficient. | 11:11 |
nigelb | oh. I see you're talking to stuart already :D | 11:12 |
poolie | jam, i'd appreciate if you can try to help the ohloh guy some more | 11:22 |
poolie | with his memory leak | 11:22 |
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:30 |
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:31 |
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:32 |
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:33 |
vila | mgz: last warning from PP, if you don't land these proposals, I will ;) | 11:41 |
vila | mgz: more seriously, you proposed a fix for http://bugs.python.org/issue12544 what happened ? | 11:45 |
mgz | it landed, but did onieric ever move from the problem python revision? | 11:48 |
mgz | and yes yes, I'll land 'em... after lunch | 11:49 |
vila | mgz: Bon appétit ! | 11:50 |
jam | mgz: 50*4 = 200, not quite 1GB | 11:52 |
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:53 |
mgz | okay, just one more branch to bother the rm before lunch | 11:55 |
mgz | ...dammit, lynx why won't you play nice with launchpad | 11:56 |
mgz | s/rm/patch pilot/ | 11:57 |
mgz | jam: each time control_dir.anything happens, you get a new repo | 11:57 |
jam | mgz: there are some cases where we allow passing in something new | 11:58 |
jam | I don't remembe rexactly where | 11:58 |
vila | mgz: they happen to be the same this week ;) | 11:59 |
jam | mgz: were bugs #866107 and bug #866111 supposed to be assigned to you? | 12:02 |
ubot5 | Launchpad bug 866107 in Bazaar "Use testresources for bzr selftest" [Medium,Confirmed] https://launchpad.net/bugs/866107 | 12:02 |
ubot5 | Launchpad bug 866111 in Bazaar "Run tests against out of process smart server" [Medium,Confirmed] https://launchpad.net/bugs/866111 | 12:02 |
mgz | ...I'll take the first one | 12:05 |
mgz | the second one I find a little more scary | 12:05 |
mgz | okay, patch pilot bothered, lunch must be had. | 12:06 |
vila | mgz: approved | 12:09 |
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:20 |
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:26 |
jelmer | jam: Ah, and just call repo.add_inventory() if it's missing? | 12:27 |
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:28 |
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:29 |
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:30 |
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:31 |
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:33 |
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:34 |
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:35 |
vila | look again ? | 12:38 |
jam | vila: I see 2 that I submitted | 12:43 |
jam | neither is yours | 12:43 |
jam | vila: maybe it bounced but you didn't get the reply? | 12:44 |
jam | want me to submit it? | 12:44 |
vila | looks landed to me | 12:45 |
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:48 |
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:56 |
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 | 12:57 |
jam | mgz: pqm only takes about 30min, you can just put up a news fix | 13:11 |
mgz | ah, missing the day of slow pqm... | 13:14 |
mgz | ah, I see the ohloh thing now, twas a question not a bug | 13:23 |
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:25 |
mgz | yeah, I'm behind, getting there... | 13:26 |
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:34 |
jelmer | vila: more-foreign-tests-fixes-{7,9} are both ready for review | 13:48 |
vila | jelmer: on them | 13:49 |
vila | jelmer: balloon ? :) | 13:54 |
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 | 13:55 |
vila | jelmer: -9 approved | 14:00 |
mgz | why so forceful vila? | 14:03 |
vila | hehe, took me two readings :) | 14:04 |
vila | jelmer: -7 approved | 14:04 |
jelmer | vila: merci! | 14:04 |
jam | jelmer: your foreign-tests-7 has 3 errors | 14:30 |
jelmer | jam: thanks, having a look now.. | 14:37 |
jelmer | hmm, the other one also has 3 failures | 14:49 |
mgz | the pqm failure for my cleanup testcases branch is the stuff of nightmares | 15:10 |
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:11 |
vila | mgz: you ignored the expected failures right ? | 15:24 |
mgz | yup, though they still confused me at first | 15:26 |
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:27 |
vila | mgz: where is this test ? | 15:35 |
vila | mgz: oh, the one about selftest itself ? | 15:36 |
mgz | I'll paste in the mp. | 15:37 |
vila | k | 15:38 |
mgz | posted. | 15:45 |
mgz | okay, result.shouldStop is getting set somehow... | 16:00 |
mgz | which still doesn't really explain the weirdness, but needs afixing | 16:00 |
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:11 |
vila | mgz: can' reproduce locally, any hint in stderr ? | 16:12 |
mgz | nope. straight up unrepoable. | 16:14 |
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:15 |
vila | but in any case, it doesn't sound worth delaying the bulk of the patch just for that | 16:16 |
=== beuno is now known as beuno-lunch | ||
mgz | okay, got this one. | 16:18 |
mgz | does PQM fork vila? | 16:21 |
vila | no | 16:27 |
vila | we'd like to eventually | 16:27 |
vila | ... but we recently went from several hours to 30 mins, we need to recover a bit from the shock | 16:28 |
* vila EODing | 16:30 | |
vila | almost :) | 16:30 |
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:31 |
briandealwis | jonnor: see the shelve command | 16:32 |
jonnor | briandealwis: shelve is what I tried, and failed as show above | 16:32 |
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:33 |
vila | jonnor: bzr version ? | 16:35 |
jonnor | vila: Bazaar (bzr) 2.4.1 | 16:35 |
vila | >-/ | 16:36 |
vila | jonnor: please file a bug | 16:36 |
vila | jonnor: 'shelf' was a typo right, you really meant 'shelve' (there was a shelf command long ago in bzrtools) | 16:38 |
jonnor | vila: yes | 16:39 |
jonnor | I have no idea on how to reproduce this issue though | 16:39 |
vila | jonnor: file a bug anyway, adding the relevant part of your .bzr.log file will give some data | 16:43 |
jonnor | vila: ok | 16:51 |
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:52 |
jonnor | it seems probable that https://bugs.launchpad.net/bzr/+bug/611739 is the bug I experienced | 16:57 |
ubot5 | Ubuntu bug 611739 in Bazaar "shelve problem on shelving directory with ignored file inside" [Medium,Confirmed] | 16:57 |
mgz | blast, didn't get to reviewing benoit's branch today. | 17:02 |
mgz | ah well, tomorrow | 17:03 |
vila | mgz: Just crossed my mind, you know pqm is running old versions of testtools and subunit right ? | 17:19 |
aidos | hello all. how do you run the tests (or better, a specific test) from the bzrlib testsuite ? | 17:20 |
=== beuno-lunch is now known as beuno | ||
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:21 |
vila | aidos: some short prefixes are available: bt -> bzrlib.tests, bb -> bzrlib.blackbox, bp -> bzrlib.plugins | 17:22 |
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:23 |
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:24 |
vila | aidos: ./bzr will run from sources, but you probably want to run 'make' before to build the extensions | 17:28 |
aidos | vila: thanks, now my test fails as expected, now onto the bugfix :) | 17:37 |
=== med_out is now known as medberry | ||
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:10 |
beuno | caravel, there's wikkid | 19:17 |
beuno | which is a wiki engine backed-up by bzr | 19:17 |
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:22 |
caravel | *apps | 19:23 |
caravel | *kind (etc., sorry typing too fast) | 19:23 |
james_w | ikiwiki too | 19:23 |
caravel | james_w: hey thanks, I had "lost" that one ^^ | 19:25 |
caravel | here we go, I'm lost in its plugin list again := | 19:28 |
caravel | would you reckon a wiki could be turned to an efficient-enough task manager somehow ? ^^ | 19:30 |
caravel | http://ikiwiki.info/todo/interactive_todo_lists/ | 19:34 |
jonnor | caravel: I'd recommend an issue tracker instead | 19:58 |
jonnor | and I do not see any reason to care about whether the underlying storage tech on a dscm | 19:59 |
=== medberry is now known as med_out | ||
caravel | jonnor: well, I do. :) To start with, stricly speaking about SCM, what are your reasons to use a DSCM ? | 20:12 |
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:18 |
caravel | jonnor: well, I have the same requirements for managing tasks, simply ^^ | 20:19 |
caravel | plus the will to push my changes, obviouly | 20:20 |
jonnor | caravel: how will conflicts be resolved? | 20:21 |
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:26 |
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 | 20:29 |
=== med_out is now known as medberry | ||
=== medberry is now known as med_out | ||
ccxCZ | icalendar files are pretty readable | 21:41 |
ccxCZ | I used conics for todos for a while, replicated with bzr, I even forked it to add yaml export/import for easy editing | 21:43 |
poolie | hi all | 22:07 |
caravel | ccxCZ: thanks for your hints, will investigate | 22:07 |
ccxCZ | for issue tracker I find roundup interesting, but that's mail-based mostly | 22:09 |
wgz | hey poolie. | 22:11 |
poolie | hi there | 22:16 |
wgz | what's the current contributor agreement arrangement? | 22:18 |
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:19 |
poolie | the page is wrong and will soon be updated, if it's not already | 22:20 |
wgz | that's a relief. | 22:20 |
poolie | yes | 22:24 |
jelmer | 'morning poolie, ɯgz | 22:37 |
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:38 |
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:39 |
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:40 |
Riddell | Timeout error here, a curious case of launchpad working better for australia than for britain | 22:42 |
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:50 |
wgz | I'm looking at bug 865753 and bug 867808 and wondering if they're running versions with that change | 22:51 |
ubot5 | Launchpad bug 865753 in bzr-builddeb (Ubuntu) "bzr-builddeb: UnicodeDecodeError" [High,Triaged] https://launchpad.net/bugs/865753 | 22:51 |
ubot5 | Launchpad bug 867808 in bzr (Ubuntu) "bzr crashed with UnicodeDecodeError in _escape_cdata(): 'ascii' codec can't decode byte 0xc5 in position 11: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/867808 | 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:51 |
poolie | http://sp.reddit.com/heavy-mallet.gif | 22:52 |
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:53 | |
jelmer | bug 86708 is with 2.7.0, so it shouldn't be relevant to your change | 22:54 |
ubot5 | Launchpad bug 19066 in firefox (Ubuntu) "duplicate for #86708 Pango-enabled firefox breaks MathML support" [Medium,Fix released] https://launchpad.net/bugs/19066 | 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:54 |
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:55 |
jelmer | wgz: see the BzrPlugins.txt attached on the second | 22:56 |
wgz | ah yes, 0 is not 9. woho! | 22:56 |
vila | . o O (No wonder I can't sleep, they are all up too) | 22:59 |
jelmer | whoa :) | 23:08 |
* Riddell offers vila some coffee | 23:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!