[00:00] hm [00:05] ? [00:10] can't remember now :) [00:10] oh right [00:10] does anyone know git smart protocol well enough to use telnet to talk to a git server? [00:11] yes [I don't, but someone does] [00:18] morning [00:56] can i remove all unknown files from a directory? [00:57] buttons840: bzr clean-tree [00:57] thanks [01:15] mwhudson, hi [01:15] jelmer: hello [01:16] jelmer: was poking at that libvdpau import failure [01:16] jelmer: comments on the bug; i don't have any questions left any more :-) [01:16] https://bugs.edge.launchpad.net/launchpad-code/+bug/445156 fwiw [01:16] Ubuntu bug 445156 in launchpad-code "vcs-import of libvdpau (git) fails: bzrlib.errors.BzrError: The remote server unexpectedly closed the connection" [Medium,Confirmed] [01:16] mwhudson, heh, ok [01:39] hmm, break-lock on lp failing to unlock. [01:42] mwhudson:d did lp recently have a rollout ? [01:42] bzr: ERROR: Server sent an unexpected error: ('error', "Cannot lock LockDir(lp-64863248:///~lifeless/tribunal/view-subunit/.bzr/branchlock): File exists: u'/srv/bazaar.launchpad.net/push-branches/00/04/a9/58/.bzr/branch/lock': [Errno 17] File exists: '/srv/bazaar.launchpad.net/push-branches/00/04/a9/58/.bzr/branch/lock'") [01:43] lifeless: no [01:43] note that its failing to lock the *lock* dir, not 'held' [01:43] well, unless spm is doing something with the cp i requested earlier [01:43] spm: ^ [01:44] mwhudson: drwxr-xr-x 2 1001 1001 4096 Jan 14 03:54 lock [01:44] ohh interesting.. note the lack of / between branch and lock on the first line. [01:44] * lifeless wonders if someting messsy is happening [01:59] jelmer: oh, i also remembered something i wanted to talk to you about [02:00] jelmer: but i guess you are or at least should be asleep now; i'll send mail :-) [02:00] mwhudson, I'm actually still here [02:00] jelmer: so about the incremental code import thing [02:01] jelmer: i'm wondering about the best way to do it [02:02] it's easy enough to go bazaar_tree.branch.pull(foreign_branch, overwrite=True, revno=local_revno + 1000) or something [02:03] but you really need to know how many revisions there are in the remote branch so you can not error by overshooting and know when the import completed successfully [02:04] sorry, perhaps we should continue this over email indeed [02:04] well, stop_revision = ... [02:04] ok [02:04] I don't feel awake enough to think about this :-) [02:04] fair enough :-) === khmarbaise_ is now known as khmarbaise [03:43] Wow. [03:43] bzr check has been running on the Emacs repository for *three days* [03:43] It's only about halfway done. [04:56] * igc lunch [05:42] "bzr checkout --lightweight lp:dosage dosage" is still taking over two minutes to run. [05:42] * spiv tries it [05:42] Is there any inter-repo caching or suchlike that I can enable? [05:43] I'm only checking out upstream sources so I can compile them -- that is, I only need to use bzr enough to say "get the latest working tree" [05:43] Well, lightweight checkouts aren't designed to be very network efficient [05:44] Which is a shame, but optimising that case hasn't been a big priority. [05:44] I'm using --lightweight because some years ago, I was told that was the most appropriate model for the workflow I described above. [05:44] FWIW, it takes less than 43s for me. [05:45] spiv: you probably just have better throughput to lp [05:45] Well, they might well be the most appropriate, but at the same time we might not have optimised your use case :( [05:45] twb: possibly, although I'm on the other side of the world to the lp datacentre (I'm in Sydney, Australia) [05:45] I'm in .melb.vic.au, on internode ADSL2+ [05:46] exetel ADSL2 FWIW. [05:46] I do see that bzr is making more round trips than it should, there is probably some low-hanging fruit there. [05:46] Oh, are you using bzr+ssh or http? [05:46] spiv: I don't have an lp account, so I assume http [05:47] i.e. have you run 'bzr lp-login'? Ah. [05:47] Ok, well that's going to be a large part of it. [05:47] And there's probably not much improvement we can make in that case, really. [05:47] No worries. [05:47] I was just checking in to see if I was still doing it the bestest way [05:47] Well, lp could provide a smart server over http, I suppose :) [05:48] I think hg does that by now [05:48] But for plain http it's always going to be a bit slow. [05:48] bzr has done it for ages, but for various mundane reasons lp hasn't deployed that yet. [05:48] Ah. Stupid lp. [05:48] Does bzr employ a packing technique to speed up fetching over "dumb" protocols? [05:49] (Partly because it's free and pretty easy to setup an lp account with an ssh key, so it's not hard to just use that and get all the benefits of bzr+ssh) [05:49] I do have an lp account, actually, I just haven't bothered to dig it out and tell bzr about it. [05:50] I only created it so I could talk to malone [05:50] Not sure exactly what you mean by "a packing technique", but bzr does compress data and try to keep it in relatively few files in a way that reduces the number of roundtrips required to find and extract revision contents. [05:51] Well, supposing you basically have one file per revision, a "pack" will condense (say) all revisions between two tags into a single file. [05:52] Right, we don't keep one file per revision, we generally keep roughly log(num of revisions) pack files. [05:52] (Or something like that) [05:53] e.g. look at http://bazaar.launchpad.net/~dosage-dev/dosage/trunk/.bzr/repository/packs/ [05:53] The obvious benefit being that dumb protocols like HTTP are better at "give me that 10MB file" than "give me those 100 1kB files" [05:53] Right. [05:54] And bzr tries hard to use things like HTTP range requests where possible too. [05:55] That particular repo has 833 revisions, but only 9 pack files as you can see. [05:55] How about HTTP/1.1 pipelining? [05:55] spiv: so the dosage guy could run some sort of "repack" command to improve new clone time? [05:55] Not sure off the top of my head, although it might depend on whether you have pycurl installed or not (if not bzr uses urllib) [05:56] twb: yes and no [05:56] Certainly libcurl can do pipelining, as long as you're using the "advanced" (not "simple") API. [05:56] twb: in general, you can run 'bzr pack' to shrink a repo down to one pack file [05:56] (And running libcurl 7.19.1 or higher.) [05:56] twb: but bzr autopacks regularly, so you shouldn't see a dramatic improvement from that most of the time [05:57] That's good to hear. [05:57] twb: and in the case of a repo on Launchpad, the read-only copy of a repo you can see isn't the same as the writeable copy visible to the branch owner, so if the branch owner runs 'bzr pack' it won't affect the repo you're cloning from. [05:58] (which is just a peculiarity of Launchpad, not bzr in general) [05:59] And of course, if you're accessing a repo via the smart protocol, how many pack files there are is basically irrelevant. [05:59] Because the client doesn't access them directly, it just asks the server to stream revisions to it. [06:00] (Most of the time, but not for the 'checkout --lightweight' case yet because no-one has spent the time to optimise it like that yet...) [06:00] twb: any other trivia about our internals I can help you with? :) [06:02] I think I'm good. [06:02] I tend to work mostly with git and darcs and hg, so it's interesting to compare notes. [06:03] Especially re. packing, since I'm involved in Darcs development and implementing packs is a goal for the next release. [06:07] twb: yeah, they really are a massive performance win. [06:07] twb: we didn't release 1.0 until a pack-based format was the default. === quotemstr_ is now known as quotemstr [08:09] * igc dinner [08:13] hi all [08:24] hi vila [08:24] hey lifeless, up late ? [08:25] yah [08:25] about to crash() [08:25] Is your sprint going well ? [08:38] bzr cleanhi [08:38] huh? [08:38] that bzr clean part must be from yesterday [08:57] so is somebody gonna ban that guy or what [09:28] * mneptok starts growing weary of this [09:32] * mneptok jostles lifeless [09:50] * mneptok summons staff [09:53] You'd think with 123 people in the channel at least one would be on the access list [09:54] none of them seems to be awake at the moment though [09:54] poolie: ping [09:57] lifeless: hi [10:03] gerard_: jam should review your patch soon (he's preparing 2.1.0rc3 so be patient :) [10:05] vila: good === radoe_ is now known as radoe [10:59] hello jelmer [10:59] poolie: hi - we were looking for an op to kickban welterde [11:00] poolie, he seems to be reconnecting every minute for the last couple of hours [11:00] is it still happening? [11:01] poolie, just did :-) [11:01] poolie: depending on your client you should have a kickban command [11:02] jelmer, poolie: if I'm reading /msg chanserv access #bzr list correctly, lifeless or abentley are your best bet. [11:05] Well, so much for that. [11:08] Ooh, K-Lined. [11:54] I need disk space. Can I safely remove the 100s of MBs in .bzr/repository/obsolete_packs/ around and about? [11:58] vila, i can be pilot next week if you want [11:58] afc yes [11:58] but only from tuesday [11:58] maybe i'll just do it the week after [12:00] are imports from the upstream debian packaging branches considered part of UDD as well? [12:00] it's impossible to register imports for packaging branches at the moment :-( [12:01] poolie: thanks [12:04] AfC: It's only kept around in case the repo is packed and your computer loses power before the new files are written to the disk or something. [12:05] poolie: I'm ok to do it until Friday, you can start from there instead if that's fine with you [12:05] Friday next week I meant [12:06] in other words the 12th? [12:06] exactly [12:10] Peng: I had 700 MB across two projects where I'd done *nothing* but bzr-git checkout upstream. Brutal. Alas. [12:10] Out of interest, if you ever did need to rescue a repository via moving in obsolete packs, what would you do with the pack-names file? [12:12] maxb: My plan is to ask lifeless to summon a magic solution. [12:12] heh [12:13] Seriously. [12:17] It'd be nice if obsolete_packs kept a copy of pack-names. === deryck is now known as deryck[lunch] [12:56] How to remove all the bzr tracked files from directory? === mrevell is now known as mrevell-lunch === sven is now known as Guest77279 [13:58] hi! i'm pushing and pulling from a remote repo that uses format "1.14 or 1.9" (and bzr 1.17dev). locally, i'm using bzr 2.0.2 and repo format 0.92. would it be safe to upgrade to format 2a locally? [13:59] sven_sandberg, not unless you upgrade the remote repo to 1.14-rich-root or 2a [14:00] jelmer, ok, thanks! [14:00] You could upgrade to 1.9 or 1.14 for a mild performance and disk space improvement. [14:01] Peng, thanks, i'll do that [14:02] 2a would be much better, but you'd have to upgrade the remote repo too, as jelmer said. [14:03] if i ask the maintainers to upgrade the remote repo to 2a, what is the minimal version that everyone else must upgrade their local repositories to first? [14:04] I believe it's >= 2.0 [14:04] * rubbs runs off to double check [14:05] You'll need bzr 1.18 or so to interact with it. [14:05] You could downgrade your repository all the way back to rich-root from, like, about 0.17, but that would be stupid, and you'd still need 1.18 to interact with the 2a repo. [14:06] I'd suggest everyone use 2.0 or above though. There are a lot of performance increases since that release. [14:07] Indeed. [14:07] The current stable is 2.0.4 [14:07] I've never had a problem with it. [14:07] and interacting with old repositories works just fine too. [14:08] 2.0.4 mugged my parents when they were coming out of a restaurant! [14:08] ha [14:09] Peng, rubbs, it wouldn't work to ask everyone to upgrade at the same time. is there a "safe path" of incremental compatible upgrades? [14:09] like, would it work if everyone upgrade to 1.18, then remote upgrade to 2a, then everyone upgrade to 2a? [14:11] The current format has poor roots. 2a has rich roots. So, no. Everyone has to upgrade to a rich-root format. [14:13] Peng, ok [14:14] Peng, are both directions problematic, or can i pull from poor to rich root? [14:14] sven_sandberg: You can pull from poor to rich. [14:15] sven_sandberg: It'll be a little slow, but whatever. [14:15] yes you can pull [14:15] but you can't push [14:15] ok, good [14:15] and you can merge from poor to rich IIRC [14:15] Rich root formats store a little bit of extra meta data, so it's impossible to push back to a poor format. [14:15] so you could almost create a mirrored rich repo [14:15] but you could run into some issues that way [14:16] rubbs: Merging shouldn't be a problem. There might be stupid bugs breaking it -- I dunno -- but they could be fixed. [14:16] Peng: that's what I was thinking. [14:17] maybe as a "steping process" you could mirror any changes made in the poor to the rich. and make the rich the new target for dev. Until everyone has upgraded. [14:17] then you can just merge in the changes from the "old" repo [14:17] pretty messy though. [14:18] One thing to do might be to have everyone use the poor repo and start upgrading. [14:18] and say in two weeks the repo will be changed to the new format [14:18] that gives everyone some time to get upgraded [14:18] just some ideas [14:18] Upgrading to rich roots is a pain no matter what. Hopefully we'll only have to do it once! [14:19] rubbs, thanks. i think it wouldn't work when someone starts pushing from their rich trees though? [14:21] i mean from the local rich trees. they'd have to push to the remote rich trees, so people who are still using poor wouldn't be able to access the changes [14:21] sven_sandberg: correct, my first idea actaully kind of sucks. [14:22] but you can force 2.x to use a poor repo [14:22] sven_sandberg: You're correct. [14:22] so maybe get everyone to switch to 2.x but use poor local repos [14:22] until you are all ready to switch [14:23] Sure, 2.0 doesn't automatically upgrade stuff. [14:23] rubbs, do you mean bzr version 2.x or is there a repo version 2.x? [14:23] Unfortunately unless you're specifically aware of the rich-root problem, it's incredibly easy to accidentally create a rich-root repository locally with 2.x [14:23] It's worth noting that "bzr init-repo" and "bzr init" will use 2a by default. [14:23] But you can do "bzr init-repo --dirstate" if you like painful old formats. [14:23] Or, you know, --1.9 or whatever. :P [14:25] true [14:25] rubbs, not sure i get it... do you mean it would work if everyone upgrade to bzr 2.x but keep repositories poor, then upgrade remote to 2a, then upgrade everyone's local repo format to 2a? [14:25] sven_sandberg: sorry I meant client (bzr) version 2.x [14:26] sven_sandberg: correct. Everyone upgrade clients to 2.x, but keep local and remote repos poor( this will take some coordination). Then when everyone has upgraded bzr, then upgrade the remote repo, then upgrade local repos [14:27] the problem comes that 2.x (bzr) will by default create a 2a (rich) repo. So you'll have to make it clear that if they wish to init a repo they ahve to explicitly make it a poor repo [14:28] rubbs, cool! that actually seems doable. i think almost everyone is using a shared repository anyways, so we're never running bzr init [14:29] I'd run some backups too just to be safe [14:29] FYI: I've just make a bzr-bash-completion release---the first ever, version 1.0.0. [14:29] So anyone of you frequently using bash to enter bzr commands might consider getting a copy to get proper completion of command options. [14:29] The danger is creating a new repo with "bzr init-repo". [14:29] scary [14:29] bialix: You had to use CVS?! [14:29] Sorry. [14:30] have used TortoiseCVS in the past [14:30] hi Peng, and all bzr [14:30] sven_sandberg: I'd possibly clone everything to a test directory and do some testing with that workflow, but I think that should work. [14:30] but I never created CVS repo with bzr init-repo [14:30] sven_sandberg: at least it should in theory. I'm pretty sure otherhave done it too. [14:30] bialix: hello [14:30] hi rubbs [14:31] bialix: I was just joking. What's scary? [14:31] rubbs, good idea. yes, i'll suggest that [14:31] rubbs, Peng, thanks a lot [14:31] Peng:the first thing I saw when connected was: `The danger is creating a new repo with "bzr init-repo".` It was scary. What's dnager? [14:31] *danger [14:32] bialix: Ahh. From my client's point of view, you joined after I said that. [14:32] bialix: The danger is that you'll unintentionally upgrade to 2a. [14:32] no, I don't. I have format1 plugin [14:33] Heh. [14:33] yep, it's not funny [15:27] vila, hi? [15:27] poolie: hey [15:28] vila, does scriptrunner not allow whitespace before the commands? [15:28] in other words they can't be indented? [15:28] possibly, I don't think there is a good reason for that though [15:29] k [15:30] poolie: quick look at the code seems to even reveal that as long as the prefix is there ($) we shouldn't care about the leading spaces (we use split)) [15:31] poolie: so just try indenting them leaving the $ at the beginning [15:37] vila, also, is there something strange about its handling of blank lines_ [15:38] poolie: they are ignored ? [15:38] poolie: they are ignored. [15:39] poolie: is that what you feel strange ? [15:42] hm [15:42] it looks like if there is a blank line in the output, the only way to make it match is to put a '...' [15:42] which is a bit gross? [15:43] rhaaa, damn, I knew there was a trick about prefixing the *commands* instead of the output :-/ [15:44] poolie: file a bug ? [15:47] poolie: looking at the code, there is another potential problem if # are needed in the input or the output lines (they will be considered as comments) [15:48] poolie: may be a good time to use a parser a bit less spartan and be able to report line numbers on errors too [15:50] vila, i think giving a diff across the whole thing would be good [15:51] poolie: ECONTEXT [15:51] a diif of the script ? against what ? [15:55] of the expected output against the actual output [15:55] oh but i see what you mean [15:55] at what point in the script did it fail? [15:55] good question [15:56] yeah, I've already encountered ambiguous cases where only the *line* can help, and even there, ideally we are not interested of the relative line into the script but by the line in the file where the script is inlined with """ """ [15:57] but once the first problem is addressed te second one is more about finding a python trick to avoid forcing the user to provide the starting line [16:01] hi poolie, vila [16:01] hey bialix [16:01] anybody knows the status of abentley work of adding less than hunk shelving support? [16:01] vila, what do you think of https://code.edge.launchpad.net/~gerard-/bzr/update/+merge/18464 [16:02] bialix, it landed. [16:02] abentley: I don't see it in 2.1.0rc1? [16:03] poolie: I asked jam to review it as I was surprised by the simplicity of the fix and was wondering if I was missing something obvious [16:03] bialix, it landed in 2.1.0b3 [16:04] abentley: there is nothing in shelve --help, and interactive short help does not suggest anything [16:04] what I'm missing then? [16:05] You need to specify a "change_editor" in your config, e.g. "change_editor = vimdiff -fo @new_path @old_path" [16:05] what this command line means? [16:06] I don't use vimdiff [16:07] is there some documentation on this feature available? [16:07] or this feature is not supposed to be used by mere mortals? [16:08] abentley: ^ ? [16:08] anybody? [16:08] bialix, "vimdiff -fo" is vimdiff-specific. "@new_path" is replaced with the path of the new version of the file, "@old_path" is replaced with the path of the old version of the file. [16:09] bialix, please give me a chance to answer your question before becoming frustrated. [16:10] there is bug: if I press ? then long short help does not mention editor, and pressing e don't launch it. Should I file it? [16:10] bialix, there isn't any documentation at the moment. The feature is meant to be used by mere mortals. [16:10] bialix, have you configured a change editor? [16:11] I'm trying [16:11] bzr traceback all the time [16:11] because there is windows path [16:11] If an editor is configured and e is not shown, that would be a bug. [16:12] specifically, change_editor must be configured for e to be shown. [16:12] ok, I finally found the right combination for windows path and it launch winmerge for me. [16:12] abentley: e is not expanded after I press ? [16:13] see: Shelve? [yNefq?] [16:13] bialix, you're right, the expanded help is buggy. [16:13] after ?: Shelve? [(y)es, (N)o, (f)inish, or (q)uit] [16:14] now I press `e` and it going for next hunk [16:14] abentley: so I need to edit @new_path to the state I want it to be after shelving, right? [16:14] bialix, right. [16:14] I will file a bug about ? [16:15] abentley: thanks for explanation [16:15] bialix, np [16:18] sftp branches in 30 seconds, bzr+ssh takes 4 minutes [16:18] expected? [16:18] I thought bzr+ssh was more efficient. [16:20] abentley: https://bugs.launchpad.net/bzr/+bug/517652 [16:20] Ubuntu bug 517652 in bzr "bzr shelve with editor support: short hunk help lists "e" but long help does not" [Undecided,New] [16:20] quicksilver: not expected file a bug with your .bzr.log, the server one and possibly some ls -lR of the .bzr/repository on both the client and server [16:21] quicksilver: which bzr version ? [16:21] vila: 2.0.3 locally; just checking the remote version [16:21] 2.0.2 remotely [16:21] quicksilver: repo format ? [16:21] quicksilver: repo format for client and server ? [16:22] pack-0.92 hmm that's a surprise [16:22] obviously this one is an old one we didn't upgrade yet [16:22] quicksilver: on both sides ? [16:23] quicksilver: see, bzr is nice with you, only it didn't find the right words, it was working happily instead ;-) [16:23] ah ok [16:23] so the thing is, sftp just uses the remote format [16:23] so the sftp version was pack-0.92 locally [16:23] quicksilver: I think there is a warning now about conversions on-the-fly but it may be in 2.0.4 or even 2.1 [16:23] but bzr+ssh hybrises it [16:23] hybridises it, I mean [16:24] so the bzr+ssh ends up as unamed (1/6/6/knit) [16:24] vila: I should upgrade it remotely and see if that helps? [16:24] s/remotely/at the remote end/ [16:24] certainly [16:25] ok, doing that. Will report new results in a moment. [16:32] vila, could you try to pilot it soon? [16:33] what ? [16:34] vila: 7 minutes to upgrade! Now testing branching. [16:35] bye [16:35] poolie: which patch ? gerard_'s one ? [16:35] hu ho, is that related ? [16:35] vila: still looks slow. "372KB/s" [16:36] moin moin [16:38] vila: sftp was attaining more like 12000KB/s; this is a local 100M network [16:38] quicksilver: ha ha ! [16:39] quicksilver: ok, well, bzr+ssh is better than sftp when the bandwith and latency are... closer to the internet ones than a local one [16:40] vila: OK, it's slightly better with the new repo format [16:40] btu still a big difference [16:40] 38 seconds for sftp, 3:14 for bzr+ssh [16:40] hmm [16:40] over 3 minutes is a long time to copy a branch :-/ [16:42] I *am* in a shared repo locally, I guess that gives it a little more work to do. [16:42] quicksilver: I think it's worth reporting your numbers if only to help reproduce the case for a next round of performance tuning [16:42] OK. Will do. Thanks. [16:43] with a little care I suppose I can do initial branches via sftp and make commits/pushes via bzr+ssh [16:43] quicksilver: wait, if your local shared repo is already populated, branch should be fast and as fast for sftp than for bzr+ssh [16:43] local shared repo should have all but one or two of the revisions, yes [16:43] it was a "very similar" branch I was checking out [16:44] vila, yes [16:44] wow, try -Dhpss and look at .bzr.log [16:44] well, and for my second and subsequent checkouts *all* the revisions would be there [16:44] after all, I just did one! [16:45] poolie: jam told me he'll review it yesterday [16:45] poolie: I'll check with him [16:46] vila: I don't think my shared repo is working correctly. [16:46] vila: how do I check? [16:46] bzr info [16:46] he's away at the moment [16:47] vila: I guessed :) but what is the magic word I'm looking for? [16:47] quicksilver: repository branch linbe [16:47] quicksilver: repository branch line [16:47] and shared repository line [16:48] vila: OK. I think I broke it all. No idea how. Building a new repo which is really shared and testing again. [16:48] poolie: rats just found jam's mail :-/ [16:49] don't let the rats into your mail! They'll ruin it. [16:49] yeah add a comma after them :D [16:56] :) [17:01] vila: YAY [17:02] vila: with shared-repos working properly it takes 7 seconds [17:02] vila: (either sftp or bzr+ssh) [17:02] quicksilver: ha, better [17:02] quicksilver: you had standalone branches under your shared repo ? [17:03] vila: my shared repo wasn't shared at all; no idea how I broke it [17:03] vila: it's literally as if I accidentally rm -rf'ed the .bzr directory [17:03] vila: quite mystified but I'm glad it all works now. [17:04] scary [17:07] vila: thanks again :) [17:09] quicksilver: ;D [17:16] hi poolie [17:16] vila [17:52] Hey, my repo is running revno 105. My web server checkout is running 99. I want to update to 102. bzr update can't be passed a revision number. I can't update a specific file to the latest revno like you can in svn. What's the best way to do this? [17:54] orattue: use merge? [17:54] orattue: bzr [pull|merge] -r 102? [17:54] the latest development version adds -r support to update btw [17:56] gerard_: yeah -r parameter on update is a really useful one [19:43] How can I check if a --fixes= has worked, before I upload the code? [19:47] doctormo: bzr log [19:49] lifeless: I can't see any fixes metadata in the log I'm seeing, what does it look like? [19:50] you may have a too-old bzr [19:51] or I may be imagining [19:51] hang on [19:51] fixes bug(s): https://launchpad.net/bugs/513432 [19:51] Ubuntu bug 513432 in launchpad-code "AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo'" [Critical,Confirmed] [19:51] ^ [19:52] lifeless: So you check the bug in launchpad to see if the --fixes has been attached? [19:53] doctormo: huh? what are you asking [19:53] What I pasted was output from bzr log [19:53] lifeless: I've done a commit with --fixes=lp:123 and I want to confirm that the meta data for the fixes is there in my local repository [19:53] run bzr log and look for 'fixes bug' [19:54] if you have an old bzr this may not show [19:54] but its not something that *can* fail [19:54] it goes into the rev object, so commit fails if you have an unknown bugtracker [19:55] lifeless: Anything I can look at if I'm using an old bzr? 2.0.3 btw [19:55] if you have qbzr installed, try bzr qlog [19:58] thanks luks, that's shows fixes and shows my code didn't work :-D [20:13]