[00:45] * SamB gripes about bzr viz not being able to run from a repo ... [00:50] lifeless: will iter_changes() yield unchanged parent directories of changed files === mario_ is now known as pygi [00:59] jelmer: look for use_record_iter in commit.py [01:03] james_w: ping [01:03] hey lifeless [01:03] james_w: can I get you to debug the stacking bug you stuffered? [01:03] sure [01:04] look at rev 4174 [01:04] it has the last change to this [01:04] and a test [01:04] pdb somewhere in its new code should help isolate whats going on [01:04] lifeless: you're welcome to come up here today. [01:05] spiv: ok, I'll head up shortly then if thats ok; we've got a lot to get across :) [01:05] ah, that sort of debugging :-) [01:06] james_w: yes :) [01:06] tomorrow then I feel [01:06] lifeless: sure. [01:06] ok [01:07] james_w: please attach bzr info -v of your source branch then [01:07] james_w: as well as checking you did push with a bzr >> 4174 [01:16] is there any docs for nested branches support? [01:20] lifeless: well, I'm almost done implementing record_iter_changes [01:21] lifeless: is iter_changes() O(delta) or O(tree) on bbc trees? [01:24] jelmer: working tree is O(tree), revision trees are a function of delta size and log(tree) [01:24] -> train to spivs, online again in ~40 [01:41] hello all [01:59] jelmer: back === ja1 is now known as jam [02:53] lifeless: IIUC iter_changes does depth-first search based on the target tree? [02:53] so if I see a directory is being processed and then see some sibling is being processed I can assume that directory is "done" ? [03:34] jelmer: I wouldn't make that assumption [03:34] jelmer: because it can jump around with renames and stuff [03:34] it might start with one file in a dir, then subdirs, siblings, then find that the dir was reparented and include the parent === UdontKnow is now known as \0 === \0 is now known as UdontKnow === thunderstruck is now known as gnomefreak [06:30] lifeless: just came here to report the stacking issue, but I see you are on it, I was just about to upload 1.14rc1, I can wait if bug 354036 fix is close [06:31] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 [06:36] BasicOSX: we're getting close, I'm landing the last bits of brisbane-core at the moment too [06:38] we are all good then, was working vila osx patches and Ian's filter registration patch, so I can hold off until that lands [06:38] BasicOSX: cool [06:50] BasicOSX: Are you planning to merge the RemoteBranchConfig stuff from r4251 of bzr.dev into 1.14? [06:51] Peng: no one specifically requested that [06:51] Eh. [06:52] lifeless: ^^ Did you want that for 1.14? [06:54] BasicOSX: Oh, I thought I did [06:54] BasicOSX: in my mail about it to the list, I noted that it fixes a regression vs 1.13 [06:57] hmm, only merge requests I see are the osx test failures and the simplify the content filter registration API [06:57] well, and bug 354036 [06:57] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 [06:58] http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C49D53C9C.2070200%40mattnordhoff.com%3E [06:58] actually thats not the one [07:01] BasicOSX: its rev 4251 of bzr.dev [07:01] I'll send a mail now [07:01] hi all [07:01] vila: Hello [07:01] lifeless: got that, (robertc) Fix handling of fallback repositories some more, just cannot find request to cherry pick it (hello vila) [07:02] BasicOSX: I've just sent one to the list [07:03] BasicOSX: That was the purpose of lp:~vila/bzr/1.14 [07:03] I apologize if I missed the initial request... oh, wait [07:04] info overload lately trying to weed through the 1.14 RC date thread :-( [07:04] :P [07:04] BasicOSX: np, that's what teams are for :) [07:04] if I can ask a small favour [07:04] please leave pqm clear for thie next cole of hours, I'm trying to land all of brisbane core [07:04] np [07:05] and finding gaps in e.g. python2.4 support for it [07:05] which are trivialish but a round trip to fix [07:05] lifeless: All of it? Like, "bzr merge ../brisbane-core"? [07:05] lifeless: fwiw, full test suite passed for python2.[456] here [07:06] Peng_: well no, I'm not planning on do that at all [07:07] Peng_: but do the point there is nothing we want to land [07:07] vila: check the _chk_map.pyx and _groupcompress.pyx files :) [07:07] vila: _chk_map is in .dev, groupcompress in p.u.c/~robertc/baz2.0/integration [07:10] lifeless: Oh. Well, congrats. :) [07:10] groupcompress up to ascii :) [07:10] lifeless: sorry to pester, but did you find the initial request to merge fallback repositories stuff? I would like to know so I can attempt to fix the holes in my tracking of merge requests. [07:12] BasicOSX: I haven't kept looking [07:12] np [07:12] BasicOSX: the fallback repositories stuff was fallout exposed by fixing the config stuff [07:12] the branch was about configs [07:12] BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it and prepare the branch for you to merge [07:12] BasicOSX: I'm not sure there was one, but as I was bitten by #354036, I merged it *in bzr.dev* and prepare the branch for you to merge in 1.14 [07:13] * BasicOSX groans [07:14] bug 354036 [07:14] Getting 354036 issue [07:14] Error: Could not parse data returned by Launchpad: timed out (https://launchpad.net/bugs/354036/+text) [07:14] bug 354036 [07:14] Launchpad bug 354036 in bzr "ErrorFromSmartServer - AbsentContentFactory object has no attribute 'get_bytes_as' exception while pulling from Launchpad" [Critical,Confirmed] https://launchpad.net/bugs/354036 [07:14] vila: thats a different bug ;) [07:14] grr [07:15] vila: so have we fixed --parallel ? [07:16] Peng: thanks for the catch on the missed merge [07:17] then #354075 fixed by matt, merged by lifeless in his 'Fix handling of fallback repositories some more' patch [07:17] should the http transport for vila's 1.14 branch work (pass the smart server code)? [07:17] lifeless: --parallel works great here [07:18] lifeless: but you mentioned problems with ec2 ? [07:19] http worked :-) [07:19] BasicOSX: you mean for pqm submissions ? [07:19] vila: yes [07:19] no, to merge your code into my prepare-1.14rc1 (lifeless requested I stay out of PQM for a couple hours) [07:19] BasicOSX: http doesn't trigger the problem [07:20] BasicOSX: oh, you can merge from lp all you want, just don't run bzr pqm-submit :) [07:20] vila: give ec2test a spin, you'll see [07:20] FAIL: test_merge.TestMergerEntriesLCA.test_one_lca_supersedes_path [07:20] RemoteException: Traceback (most recent call last): [07:20] File "/home/bzrtest/test_branch/bzrlib/tests/test_merge.py", line 1598, in test_one_lca_supersedes_path [07:20] self.assertEqual, [], list(merge_obj._entries_lca())) [07:20] File "/home/bzrtest/test_branch/bzrlib/tests/__init__.py", line 1055, in expectFailure [07:20] raise KnownFailure(reason) [07:20] KnownFailure: We don't do an actual heads() check on lca values, or use the per-attribute graph [07:20] lp = smart server [07:20] ? [07:20] lifeless, BasicOSX : Someone else than *me* triggers the lp/pqm bug ? Hurrah ! Not jinxed anymore ! [07:20] still [07:21] BasicOSX: lp: urls reoslve to using bzr+ssh and thus a smart server [07:21] lifeless: I can't do that, I don't have access to ec2, not even sure I can find boto module ? [07:21] yep, and I'm getting bit but the smart server bug, so I just got vila's patch via http [07:22] BasicOSX: oh right, I'm synced() now :) [07:22] vila: sign up :) [07:22] vila: see the company cloud computing policy in the all hands list archives [07:24] lifeless: I'll look [07:25] By the way, it seems that we have more "warnings.warn("%r was gc'd while locked" % self.repr)" these days nist of them (if not all, involving a LockableFiles( gee how did I type that reverse ? [07:26] heh [07:53] -> home, groupcompress has landed, I'll be landing the remaining bits very soon. [07:53] well, ->home shortly [08:24] vila: the answer btw to InterCHKRevisionTree is s/development5/development/ [08:24] vila: found the ec2 doc stuff? [08:25] -> home now [08:42] lifeless: I need to find what login/pass I should use to access allhands archive first :-( [08:49] Well, if it's allhands, I presume you need a fingerprint rather than a password 8-} [08:51] time to upgrade ff then :) [09:06] BasicOSX: around? [09:11] lifeless: thanks for landing that stuff today [09:12] * igc dinner - bbl [09:48] lifeless: still around ? [09:50] I'd still prefer to run locally (for many reasons including ease of debugging). So my question is: do you feel that the problem you encounter is related to the tests protocols rather than any ec2 specific reason ? [09:52] lifeless: by 'locally' I mean connecting via ssh in my LAN to get a close-enough approximation of course [09:53] lifeless: and also because that's a setup I want to be able to use from my laptop to my "data center" :-) === bob2 is now known as Guest95719 === Guest95719 is now known as bob2 [10:48] igc: nearly done [10:48] vila: yes, I'm around [10:49] vila: I would like it if you were familiar enough with bzr-ec2test to debug problems when it is used [10:49] vila: thus, I plan to drag you kicking and screaming through it once :) [10:51] lifeless: ha, I thought so but was unsure :-) [10:53] vila: concretely it is failing to de-and-re serialise from ec2 [10:53] which I haven't had time to debug myself test. [10:54] lifeless: so it's not directly related to my last patch (as in, it was failing before ?) [10:54] I think so [10:54] :) [10:54] devil :) [10:56] well [10:56] I figure a little latitude is due, for doing the heavy lifting to get you your desired parallel suite :) [10:57] vila: I have a separate favour for you to do though, and this is rather more important. I'm about to land --development6-rich-root [10:57] huh ? We still separate rich-root ? [10:58] its the only one [10:58] no dev6 [10:58] and aaron has said subtrees need more stuff so leaving out for now [10:58] ha, to underlined that it *is* rich root [10:58] yes [10:58] ok [10:58] *do-not* want random upgrades and folk having deep troubles [10:59] * awilkins applauds the lack of not-rich-root [10:59] Didn't we say we'll call it --dev6-rich-root-eat-your-dog ? [11:00] --dev6-rich-root-cat-taxidermist ? [11:00] anyway, what favour ? (The more you wait to ask, the bigger is should be, the more I'm frighten :) [11:00] awilkins: don't touch cats [11:00] Toxoplasmosis? [11:03] vila: merge all the components of brisbane-core from bzr.dev to a single branch and then that into 1.14/get BasicOSX to merge it into 1.14 [11:03] vila: *note* I *have not* and do *not intend* to merge the brisbane-core branch directly. [11:03] vila: it has content we don't want to land in bzr.dev at this point. [11:04] lifeless: right, so cherry pick from bzr.dev ok. Two things, [11:04] The sucky thing about not having a non-rich-root format is that the Big Rich Root Transition will have to take place before I can use it locally on most projects. :\ [11:05] lifeless: Do you have some reference branch I can use for verification purposes (though one) [11:05] lifeless: two: that means losing the annotations or did your (and Ian's) submissions somehow preserve them ? [11:06] lifeless: if answer to two is yes, don't bother explaining, I can understand why, just want to be clear [11:06] What exactly is the reason for things not being bi-directionally compatible with rich-root? [11:06] why aren't floats bidirectionally compatible with ints? [11:07] That isn't "exactly" [11:07] rich-root has data non-rich-root can't represent [11:07] Yes, but what is it? [11:07] awilkins: root data :) [11:07] Ginger? Valerian? [11:07] awilkins: that data makes root rich [11:07] an id for the root directory of a branch [11:09] vila: they are gone, we have used --author [11:09] awilkins: and versioning of the root [11:10] awilkins: which we use in a number of merge corner cases, and for nested trees. [11:11] The band-aid needs to be ripped off! .... of course, it doesn't matter much to me, the majority of branches I use are rich-root so I can keep my manager happy with svn commits [11:13] vila: btw its 120 seconds for me to run the test suite with 2 ec2 instances [11:14] lifeless: right so, from bzr.dev log that means revnos 4262 4261 4260 4259 4254 4248 4247 4246 4245? 4244 4243 and the one where you land the --dev6 format ? [11:14] lifeless: 120... hmpf [11:14] lifeless: that doesn't include bzr-loom of course :-) === AnMaster_ipv6 is now known as AnMaster === Mez is now known as CrazyShoe === CrazyShoe is now known as Mez [11:36] igc: ping [11:53] * lifeless tapdances on igc's toes === siretart_ is now known as siretart [12:11] vila: it passed tests in bzr.dev because many tests were not running for it [12:12] vila: grab my integration branch if you want to see it blow up ;) [12:12] lifeless: errr, context ? ec2 ? bbc ? [12:13] lifeless: here to help - which branch should I grab? [12:15] igc: my integration branch [12:15] vila: bbc [12:16] igc: if you run bzrlib.tests.workingtree_implementations.test_eol_conversion.TestEolConversion.test_eol_native_with_crlf_i [12:16] for selftest [12:16] it should fail with a clearly wrong line ending [12:16] I see [12:16] AssertionError: not equal: [12:16] a = 'hello\r\nworld\r\n' [12:16] b = 'hello\nworld\r\n' [12:16] for instance [12:17] give me a clear pointer at whats likely wrong and I'll happily fix. right now I'm fixing real issues with tests that were incorrectly not enabled in bbc that became clear as I did the integration [12:17] s/real/other real/ [12:19] lifeless: grabing the branch now. The code on lp is up to 4248 and due for mirroring again in 2 hours so I can't just use loggerhead there === thunderstruck is now known as gnomefreak [12:23] igc: sorry yes :) [12:23] igc: regardless loggerhead wouldn't help you I don't think [12:23] np - it's down now [12:23] so, found an issue with labels [12:23] without labels in the pack [12:25] two packs with different content can then collide, but the indices are no longer equivalnet [12:25] [tests fail] [12:26] lifeless: ./bzr selftest TestEolConversion --no-plugins -1 passes for me [12:26] on 4249 [12:26] of your integration branch [12:26] hmm [12:26] set LANG=C [12:26] hmm [12:27] sadly bzr is the only vcs that has merge instead of pull if the remote diverged [12:28] 'has'? you can merge in git in that situation (after fetching) [12:29] ronny: try bzr merge --pull [12:30] hg and git allow me to pull first, merge later [12:31] you can bzr pull to your local mirror of that branch (and if it is in a repository with your branches, it is space efficient) [12:31] ronny: bzr can do that too, via fetch [12:31] bzr's mass branch management is a bit lacking alas [12:32] lifeless: so fetch pulls a dangling head into the backing repo? [12:32] lifeless: setting LANG=C doesn't break things for me [12:32] hmm [12:32] I'll try a wider set of tests [12:33] i love how this shit differs - in hg/mtn pull is history sync, in bzr/git it has some merge potential (and bzr is the one that needs explicit merge) [12:36] lifeless: will the fetched remote data get any special marker other than showing up in the heads? [12:36] igc: interesting [12:36] ronny: no [12:36] lifeless: so the filtered views tests are failing for me cause you deleted development-wt6 - trying them now with development-wt6-rich-rott [12:37] roo [12:37] root [12:37] igc: yes,they are passing for me [12:37] I have some uncommitted fixes fixing most of the tests [12:37] it needs to go as well and be replaced with you new format [12:41] lifeless: so filtered view tests pass on development6-rich-root, development-wt6-rich-root needs deletion if you haven't done it already [12:42] igc: yes, done [12:43] lifeless: did you try --no-plugins? [12:43] hey lifeless, igc [12:43] hi jelmer [12:43] vila: ping [12:44] vila: You mentioned using factory.stdin.getvalue() in your review [12:44] vila: but the rest of the file also uses factory.stdin.readline() and the main point is checking the position of the stream [12:47] lifeless: if you put the output from bzr diff in a pastebin, I'll apply that and run the tests again [12:47] jelmer: I think the comment says: ensures stdin is empty no ? Oops, no, the previous test is with a non-empty stdin, sorry, forget that remark then [12:49] vila: ok, just making sure I wasn't missing anything. Thanks again for reviewing, I've fixed the other issues. [12:49] igc: sure, one sec [13:00] http://paste.ubuntu.com/146177/ [13:00] sorry, phone call [13:04] igc: ^ [13:04] igc: I'm going to recommit in a minute, as I had to back out some of the cleanup [13:04] and try it again [13:21] ok ec2testing [13:21] igc: if it fails on the NoEol stuff, I'm going to shove it a pqm [13:21] I think it might be me ;) [13:22] lifeless: might be. bzr selftest eol filter --no-plugins -1 works fine for me with your patch .. [13:23] and visually inspecting it, it looks fine [13:23] igc: yea, I can't see anything in this breaking it :( [13:23] I got out of bed to help so I'll head back there now [13:23] igc: I'm so sorry [13:23] igc: where should I look if it still breaks [13:23] lifeless: np. email me if there's still an issue and I'll look into it first thing [13:24] I'm staying up till this is landed [13:24] I don't need you to fix it, just to point me at the code areas that are potentially implicated [13:24] well bzrlib/filters/eol.py is the starting point [13:24] beyond that, it depends [13:25] sorry - that's not much of an answer [13:25] thats ok [13:25] I will follow my nose as needed [13:25] sleep well, and sorry again [13:26] lifeless: good luck and I'll possibly be up early - hard to tell as the chemo makes me very both very sleepy and very awake depending on god knows what [13:26] so please email any issues [13:26] night all [13:28] will do [13:32] bombs away [13:56] lifeless: your pending submission in pqm is the last I should backport to 1.14 right ? (It passes tests here) [13:56] yes [14:02] vila: I'm wondering what to do with smtp as the current implementation asks pre-emptively [14:04] vila: ideally we wouldn't always be doing that but only in the cases where the server requires us to [14:04] vila: but that seems impractical (impossible?) for smtp [14:05] jelmer: smtp starts by using its own smtp_username and smtp_password config options, I'd say it should use authentication.conf instead [14:06] jelmer: iow, out of scope for your fix IMHO [14:06] vila: the problem is get_user() will now return getpass.getuser() rather than None if there's no user configured in authentication.conf [14:06] vila: and previously it would skip authentication if None was returned [14:06] jelmer: can I ask a favour? [14:07] lifeless: you can always ask :-) [14:07] jelmer: ... say yes to my next request [14:07] jelmer: may I kill your pqm job, its 11PM, want to land development6 and sleep [14:07] lifeless: sure, go ahead [14:08] tanks [14:13] lifeless: please let me know when yours is done so I can requeue mine [14:14] jelmer: I'm pretty sure lifeless will be asleep when pqm lands its patch :) But nothing forbids you to queue now, I think that was the last missing patch [14:14] vila: I will be awake till it lands [14:14] lifeless: sorry no offense intended :) [14:15] vila: only way to be sure [14:15] non taken [14:15] lifeless: good ! So you may have a look at lp:~vila/bzr/bcc-1.14 and tell me if everything looks fine so far [14:15] :) [14:16] lp:~vila/bzr/bbc-1.14 of course [14:16] to your list above [14:16] 4257 [14:16] indeed, just merged it [14:17] vila: any idea about smtp? [14:17] lifeless: errr, was about to merge it (not pushed) [14:17] :) [14:18] vila: I could add a "return_non_if_default" boolean parameter but that just seems plain wrong [14:18] jelmer: consistency is good, I think smtp should align to either http or getpass.getuser() [14:19] vila: but the new behaviour makes unauthenticated smtp impossible [14:19] as get_user() will never return None [14:21] lifeless: I just got a "success" message from PQM and my branch was merged [14:21] jelmer: odd... [14:21] jelmer: unauthenticated http is possible, do the same :-) [14:22] vila: yes, but in the case of http we only ask after the remote host gives a "Permission denied" [14:22] jelmer: sure, I was trying to get some time to think :) [14:22] jelmer: That reminds me about svn+ prefixes [14:23] vila: :-) [14:23] awilkins: what about them? [14:24] jelmer: I seem to think that if your web server refuses access to the locations that bzr probes to determine whether a web server is a repo, things just stop [14:24] I should make a more coherent report [14:26] jelmer: so smtp._authenticate() says: """If necessary authenticate yourself to the server.""", so there should be a way to find if auth is necessary [14:26] In the worst case it means: try to send, catch auth error, authenticate, send [14:26] there is smtplib.SMTPAuthenticationError .... [14:27] ... whose doc string says " Most probably the server didn't accept the username/password"... I love the most probably part :-/ [14:28] vila: yeah, SMTP sucks [14:28] jelmer: probably smtp servers requiring auth suck less :-) [14:28] vila: The annoying thing here is that we probably won't know whether we need authentication until we've tried sent a full email [14:29] s/sent/to send/ [14:31] jelmer: indeed, that's the way http achieve auth, try without and if it fails try with auth === sabdfl1 is now known as sabdfl [14:35] lifeless: ha, 4259, the fun stuff :-( === abentley1 is now known as abentley [14:37] vila: what about an optional default= argument to get_user() that defaults to getpass.getuser() ? [14:37] vila: smtp could set that to None [14:37] and keep behaving the way it does atm [14:38] jelmer: if you add a FIXME in smtplib about converging and/or addressing the problem, that sounds perfect for your submission [14:38] that would keep smtp in the current state but at least support prompting for http [14:38] vila: cool, thanks [14:39] yes :) [14:39] vila: see the pyrex issues? [14:39] also: http://pqm.bazaar-vcs.org/ - the eagle is landing [14:40] jam: ^ :) [14:40] lifeless: not yet (but I suspected that when you mentioned the problem), I'm in Resolve confclits in NEWS [14:42] lifeless: /cheer /train [14:42] Though your post about duplicate content was a bit concerning [14:43] I have some thoughts about exploiting duplicate content within a group, but having this across .pack files ... [14:44] jam: yes; it is rather pathological, but worth resolving in some way for production version [14:45] lifeless: so... we could go with some sort of labels as an easy fix, or push more for getting text content into a chk structure [14:46] I'm concerned about the CHK index exploding even further... [14:55] jam: indeed [14:58] landed in bzr.dev [15:04] vila: cool [15:04] jelmer: go for it [15:06] lifeless: thanks, it's already in though :-) [15:06] vila: so are you good to get a passing testsuite version for 1.14? [15:06] I run selftest at each commit, I'm at bzr.dev@4261 so 3 more commits to go [15:07] cool, I'll hang about a bit then [15:07] err 2 even [15:07] as I know you have fast tests :) [15:07] indeed, could not have afford to do that otherwise [15:11] lifeless: yeah for the big fat NEWS entry about bbc :) [15:15] lifeless: ready to merge in 1.14 pushed at lp:~vila/bzr/bbc-1.14 care to have a look, jam too ? [15:15] still running the tests, will do a 'make check' after that [15:16] vila: I'm shattered; the mainline is done, I'm happy to hand off [15:16] lifeless: ok [15:16] lifeless: good job, sleep well, no test failure to report so far :-) [15:16] vila: cool, thanks. [15:17] vila: so is that cherry-picking brisbane-core into 1.14? [15:17] lifeless: is this the bug you were looking at with spiv: [15:17] ErrorFromSmartServer: Error received from smart server: ('error', "'AbsentContentFactory' object has [15:17] no attribute 'get_bytes_as'") === ubott2 is now known as ubottu [15:17] jam: yes [15:17] k [15:17] jam: I mailed the list the bug number [15:17] because I just failed to branch vila's code [15:18] the fix is to upload more content [15:18] bug 354036 [15:18] yes [15:18] jam: yes, it should be: bzr-1.14 + (bzr.dev@4265 - everything not related to bbc) [15:18] vila: apply the fix from bug 354036 to the bzr you use to push, remove the branch and push again [15:19] well, for now I can just branch from "http://bazaar..." [15:19] indeed [15:20] well, I'm halting() or I'll be more than tired tomorrow [15:20] lifeless: I use bzr.dev@4263 to push so the fix should already be included [15:20] Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text) [15:20] vila: we haven'tlanded the fix for that bug [15:20] Error: Could not parse data returned by Launchpad: Unknown host. (https://launchpad.net/bugs/354036/+text) [15:20] grrr [15:21] lifeless: There's an error in the docs for development-rich-root: It says it's interchangeable with pack-0.92, not rich-root-pack. [15:21] ubottu you didn't help here ! That's the second time I cross the bugs and that you can't display them >-/ [15:21] Error: I am only a bot, please don't think I'm intelligent :) [15:21] ubottu: that wasn't exactly what I was thinking :-) [15:21] Error: I am only a bot, please don't think I'm intelligent :) [15:22] Peng_: thanks. vila/jam if you could fix that oversight that would be grand [15:22] * lifeless goes [15:25] uuuurgh, can't pull ~spiv/bzr/stacking-inventory [15:27] ok, pulled with bzr-1.13 [15:28] and pushed with ~spiv/bzr/stacking-inventory at lp:~bzr/bzr/bbc-1.14 [15:29] jam: can you pull that one ? [15:29] vila: I already fetched it with http:// [15:29] but I'll try again on another machine [15:29] jam: rats, I missed that one [15:31]