[00:01] * poolie looks [00:13] ok [00:25] the bzr-builder "parser" is a little sad making [00:30] oi! [00:31] james_w: hi :-) [00:31] it' [00:31] hi mwhudson :-) [00:32] output from "bzr merge": [00:32] deleted misc [00:32] ... [00:32] Path conflict: misc / misc [00:32] "bzr st": [00:32] removed: [00:32] misc/ [00:32] ... [00:32] conflicts: [00:32] Path conflict: misc / misc [00:33] ls misc*: [00:33] No matches: misc* [00:33] what sort of conflict is that? [00:35] james_w: exciting? confusing? There are lots of adjectives ;) [00:35] mwhudson: I don't have anything specifically against using a "proper" parser, I'd just like it to pass the tests, or equivalent ones [00:36] It's not inexperience that led to that implementation [00:36] spiv: I'd say both of those apply [00:36] I've no idea how to resolve it, or even why I thinks I need to [00:36] james_w: it would be nice if there was a grammar for recipes i think [00:37] yes [00:37] it's not that the current parser is bad, but it's a bit of a blob [00:37] separate lexing and parsing might be nice [00:37] and then it would be nice if the parser was generated from that, so it was confirmed to be nice [00:37] but maybe that's ott for something simple [00:38] james_w: my use case is wanting to rewrite the branch references in a recipe [00:38] lexing is hard in this case [00:39] i guess line.split() is a fair approximation of what's possible actually :) [00:40] yes [00:40] plus, "bzr tag 'a tag'" would lead to some issues [00:40] and spaces in URIs may be a bit of a pain with bzrlib [00:41] %20 ftw i guess [00:41] but you can't put a space in the url of a branch on launchpad so... [00:42] true [00:42] the issue is that bzr transports take strings, and there's no way to tell if whether it is escaped or not [00:44] e.g. https://bugs.edge.launchpad.net/bzrtools/+bug/310631 [00:44] Ubuntu bug 310631 in bzrtools "bzr patch doesn't understand query strings in URLs" [Undecided,New] [00:45] james_w: i think bzrlib generally assumes that urls are escaped [00:46] so that looks like a straight up bug [00:53] hm, i guess you're right, it's a bit muddled [00:55] bzrtools is doing urlutils.normalize_url() on the path, which might be wrong [00:55] not doing it might give other problems though [00:56] no, it's the split path and get that's messing things up [00:56] >>> urlutils.normalize_url('http://python.org/?arg=value') [00:56] 'http://python.org/?arg=value' [00:57] ah [00:58] that bug's all over the place in my code then [00:58] well [00:58] i don't know what the right fix is [00:59] i guess httptransport's .get() is broken [00:59] but fixing it might break other stuff [01:02] james_w: bzrlib.transport.Transport._unsplit_url says in the docstring [01:03] Build the full URL for the given already URL encoded path. [01:03] but then escapes the path anyway === r0bby_ is now known as r0bby [02:26] jam: https://ec2-sshd.dev.java.net/ [02:46] james_w: still here? [02:47] yep [02:49] james_w: where in the world are you at the moment? ;) [02:49] home [02:49] physically, if not temporally. [02:49] yikes [02:49] james_w: we have this need to rewrite the branch urls in a recipe [02:50] yes [02:50] partly this relates to the way we plan to store the recipe for the moment, but we'll also need it to inject the credentials for building from private branches [02:51] james_w: i think it makes sense for this code to be part of bzr-builder [02:51] yep, in some form [02:52] james_w: i'm not sure whether the input to this functionality should be the recipe text or the BaseRecipeBranch [02:52] the problem with starting with the latter (and attacking the manifest generating code i guess) is that you'll lose comments and formatting [02:52] not sure offhand [02:53] it would be possible to preserve that [02:53] fugly, but possible [02:53] unless you make the parser smarter [02:53] yeah [02:53] preserving comments is probably something we should do anyway [02:54] if you take the text as input, you can probably just remember where the branch urls came from and string manipulate them out [02:54] james_w: preserving comments in the manifest, you mean? [02:54] yeah [02:54] ok [02:54] well that's an argument towards making my changes more "core" and less of a parallel hack i guess [02:55] which is probably a good thing [02:55] yeah [02:56] I dread the code to preserve though [02:56] I think we might need to change the model to make it palatable [02:56] or maybe not too much [02:57] it's not clear to me where you'd put comments in the model [02:58] perhaps a new instruction that's a null, but stores the comment? [03:02] james_w: i guess [03:03] james_w: edge cases galore though [03:03] james_w: spot the difference! http://pastebin.ubuntu.com/337738/ [03:04] them the rules! :-) [03:04] mwhudson: makes perfect sense ;) [03:04] we could fix that case if you want to file a bug though [03:05] try putting 3 spaces in the middle line though :-) [03:05] oh and you can't have comments at the end of significant lines [03:06] james_w: i noticed the mandatory two space indent, at least that gets around some of python's complexity here :) [03:06] that's one of Mark's :-) [03:06] heh heh [03:09] james_w: is not being able to put comments at the end of a line a feature? [03:10] it leads to some slightly strange error messages [03:10] I don't think it is [03:10] ok [03:11] * mwhudson gets his bug filing hat on [03:12] james_w: https://bugs.edge.launchpad.net/bzr-builder/+bug/487174 reminds me to ask you what the branch ids are for [03:12] Ubuntu bug 487174 in bzr-builder "Doesn't enforce uniqueness of branch ids" [High,Triaged] [03:15] revno: [03:15] and derivation when we implement that [03:19] james_w: oh, in the debversion? [03:19] yeah [03:20] makes sense [03:22] james_w: i filed three bugs, i guess you got emailed about them [03:23] I do, thanks [03:24] it keeps asking me for password how can i unbind [03:24] if it says i am unbound? [03:26] i type "bzr unbind" - it asks me for passwrod - why? [03:26] i type it in [03:26] it says i am unbound allready [03:26] how can i just work locally? [03:29] james_w: i worry a bit about the interaction of # and the run command [03:29] treeform1r: what does bzr info say? [03:47] * igc lunch [05:00] anybody know why bzr is stuck at 1.x in the Fedora repos, even though the package was updated in June of this year? [05:27] gbbzr: no, but you could ask on the list [05:27] abadger i think is involved with it but he's not here now [05:36] hello [05:37] does Gordon Tyler hang out on IRC? [05:39] jml: I think he does, sometimes [05:40] jml: nick is dOxxx I think, maybe +/- an x [05:41] spiv, thanks. [06:30] I see references to “No handlers could be found for logger "bzr"” in various search results [06:30] but no real clue as to why it would suddenly start happening. [06:31] I gather it's to do with the fact that logging hasn't been properly initialised, but why would that suddenly start happening without a change in Bazaar for several weeks? [06:37] bignose: perhaps because bzr couldn't open ~/.bzr.log? [06:37] (or wherever 'bzr --version' says the log file ought to be) [06:38] argh [06:38] bignose: IIRC a relatively common cause is 'sudo bzr' [06:38] why does that file occasionally get owned by root [06:38] well, grumble mumble bumble. [06:39] I *think* there's a bug report about that somewhere, although off the top of my head I'm not sure what bzr can do about it. [06:39] perhaps a FAQ entry would be good on that. [06:39] Well, I suppose bzr could emit a clearer warning. [06:39] yes, that too. [06:40] it would be good to say explicitly that Bazaar doesn't have the permission it needs to its own log file. [06:46] spiv: so THAT's what that means. I've been happily ignoring it till now. face? please meet palm. Gah. I should have just asked... lala me [06:48] spm: heh [06:48] * spm emails losas with this fine tidbit of info [06:50] It's bug 354843 FWIW [06:50] Launchpad bug 354843 in bzr "better handle failure to open ~/.bzr.log - Bzr should be smart about who owns ~/.bzr.log" [Medium,Triaged] https://launchpad.net/bugs/354843 [06:50] (And I just marked two other bugs as dupes of that!) [06:56] Oh hmm we have two 'Critical' bugs, I hadn't noticed that. [07:28] I really, really want to depend on launchpadlib.uris [07:36] jml: sounds a bit like an ad campaign for a cleaning product... "launchpadlib... you can depend on it!" [07:36] heh [07:37] hi all [07:39] spiv: I don't think #461992 is critical, a 700MB *VM* that can't co a 1GB file... gee, increase the VM ram... [07:41] jml: ECONTEXT, I'm sure launchpadlib.uris is great why advertising it here ? :D [07:41] s/great why/great BUT why/ [07:42] Here I go, ruining my first joke of the day with stupid typos... not even a good joke... [07:42] vila, because I could delete code from bzrlib.plugins.launchpad [07:42] ha! And you fear the consequences :) [07:42] vila, well, bzr can't have a hard dep on launchpadlib, realistically [07:42] yeah, but I thought the plan was to make it a soft one [07:43] vila, also, launchpadlib.uris was added to launchpadlib mere hours _after_ the last version of launchpadlib was released [07:43] LOL [07:44] Gimme the new toys ! [07:44] it was released last in October [07:44] argh [07:44] there's been a whole release of Ubuntu since then. [07:45] jml: don't get me wrong, there are very good reasons to use the new toys :) [07:47] Hi! Is there some public official way to have bzrlib determine the relation between two revisions? I'm thinking along the lines of Branch._revision_relations, preferably with the caching Repository.__heads as the backend graph. [07:52] MvG: I guess doing g = repo.get_graph(); heads = g.heads([revA, revB]) gives you that info with reasonable caching. [07:53] MvG: I think it would be reasonable to promote _revision_relations to a public API somewhere, although it probably doesn't belong on branch. [07:53] I think so, too. [07:54] I guess I'll write a mail requesting that. Last time I wrote such a mail, I was told the function I requested already exists (Repository.iter_reverse_revision_history), so I thought I'd ask here first this time. :-) [07:54] MvG: so what I'd do then is rely on _revision_relations and file a bug about promoting it [07:54] Heh. [07:54] Well, it's possible that it already does and I just haven't thought of it :) [07:54] If it does, then presumably I can remove _revision_relations and cut down on duplicated code ;) [07:55] Hmm, I think it probably makes sense a method on Graph. [07:56] I suppose Graph.find_difference sort of gives you the same thing. [07:57] Dunno what the performance of that is lie. [07:57] like, rather. [07:58] There's Graph.is_ancestor, which gives you part of the info. [07:58] Graph.find_difference does much more: it seems to list all revisions which are ancestor of one head but not of the other. Way too much overhead. [07:59] But no equivalent method that I can see. [07:59] Graph.is_ancestor is implemented in terms of heads, so using heads directly to determine both directions should cut my costs by hald at least. [07:59] _revision_relations is also implemented in terms of heads. [07:59] Yes, that's how I found it. [07:59] But only makes a single heads call, of course. [08:00] Anyway, a patch to move _revision_relations to Graph with a public name makes sense to me. I'd happily review a patch to do that, presumably we'd want to add unit tests for it though. [08:07] spiv: Why to graph, not to repository? Repository.__heads is a special caching graph instance, and reusing that instance seems benificial to me. [08:12] MvG: Repository.get_graph() should already be caching, so I don't think there's a practical difference [08:13] Repository.get_graph() does cache the graph itself, while Repository._heads does cache results from heads requests directly. [08:13] Well, I suppose __heads is specially optimised for heads() lookups. [08:14] But if it's that useful I would think it should be cached on graph rather than the repository. [08:15] MvG: Actually Repository doesn't have __heads/_heads, you're looking at CommitBuilder I think [08:16] MvG: which probably explains why there's no code that resets the _heads cache during Repository.unlock, and probably also ensures the memory impact of that cache will be small :) [08:17] spiv: You're right. I guess I'm too used to Java, with its one class per file paradigm. [08:18] On https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth/+merge/15853, poolie points out that the patch will cause launchpadlib to be loaded whenever bzr is loaded [08:18] OK, so we assume that caching all heads requests might be too expensive, and furthermore that we can get at a reasonable caching graph using Repository.get_graph(). In this case a method in Graph would really be the better alternative, I guess, yes. [08:18] MvG: right [08:18] I thought plugins were loaded lazily [08:19] if they aren't, how can I do a conditional lazy import? [08:19] MvG: if you find with that that performance isn't good enough, then we can always try to think of ways to do better :) [08:19] jml: they can't be; otherwise how can a plugin e.g. decorate a builtin command the way bzr-loom does? [08:19] jml: however, plugins can and should use lazy_import themselves [08:20] spiv, ok. that's good to know. [08:20] spiv, how do I do a lazy import that behaves like the one in the patch? [08:20] jml: in my ideal world, a plugin's __init__ would register commands or hooks or whatever it needs to do, and have the rest of the code lazy imported. [08:20] * spiv looks [08:21] jml: so, you want lp-mirror to only exist if the dependency is available? [08:21] jml: why not make it always exist, but give an error if the dependency is missing? [08:22] jml: I think that might be a nicer UI too, it seems more discoverable to me [08:22] spiv, I guess I could do that. [08:22] "Why don't I have lp-mirror, I have the launchpad plugin!" [08:22] jml: and in that case, the lazy import can just be a good ol' fashioned local import in the run method of that Command if you like. [08:22] spiv, I can imagine it being a little confusing to have lots of available commands that you can't actually use. [08:23] Well, let's worry about that when we have lots rather than one? [08:23] * igc dinner [08:24] I can imagine making some infrastructure for that, maybe provide something like "bzr plugins --check-deps" that plugins can hook into? [08:24] But we already have this situation with e.g. SFTP support without causing much drama. [08:25] (If you don't have paramiko I believe attempts to use sftp:// URLs will give you a relatively friendly error about needing paramiko) [08:26] Anyway, I'd argue it's no more confusing than commands simply not existing even though you think you've installed the plugin that provides it. [08:26] OK [08:27] (Or with a bundled plugin, that you think you've installed the version bzr that bundles the plugin that provides it... see, confusing ;) [08:28] jml: I'll add a brief note about my opinion to the review for posterity [08:31] spiv: I guess I'd rather return a number (e.g. -1, 0, 1) instead of a string, as numbers are cheaper to compare. Opinions? [08:32] MvG: strings are almost as cheap to compare, especially if they are literals that contain strings that can be Python identifiers, because those strings are interned [08:33] MvG: so the comparison in that case is basically just a pointer comparison [08:33] MvG: I'd be happy have module-global constants for those strings, I think. [08:33] MvG: but I really doubt that the cost of that comparison will be significant compared to the cost of the underlying heads call! [08:34] Probably true, yes. [08:34] MvG: If you measure a performance problem, I'd be very happy to look at the measurement and figure out improvements, though :) [08:34] MvG: but I strongly advise against micro-optimisations that impact code clarity without evidence that they'll have a significant effect. [08:35] Agreed. Didn't know about Python cheaply comparing such things. [08:36] spiv: would you agree that the plural in "_revision_relations" is wrong? There is only one possible relation between any two given revisions. [08:37] MvG: yes [08:37] MvG: I've no idea why I never noticed that before :) [08:39] MvG: as far as Python cheaply comparing such things, I've skipped over a bunch of mostly unimportant details about how CPython compares ints and how it compares strs... But the general rule of measure before guessing about optimisations certainly applies :) [08:40] MvG: I'll happily chat about CPython implementation trivia sometime if you like, but not tonight :) [08:42] spiv: I guess I also had some concerns about typos in literals on the part of the caller, but constants take care of this. By the way, is there some python idiom to declare a constant as opposed to a variable? [08:48] MvG: CONSTANT = 'value' [08:49] MvG: rather than: variable = 'value' :) [08:49] But python doesn't enforce constantness on these, does it? [08:49] No, but it doesn't enforce constantness on anything, more or less :) [08:50] Except the evaluation of 1+1, and I've seen an extension module to change that ;) [08:50] spiv: By the way, I sent my mail requesting the method: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/64622 [08:50] MvG: thanks! [09:14] I'd like to make a checkout (or branch) of only a subdirectory in a repo. Is that possible? [09:17] sjamaan: I'm no expert, but I'd guess no. I assume you'd have to branch the whole tree, then you could split of a subdirectory into a separate project if you want to. [09:18] Although I assume that if you split, changes to that subdir are at least more difficult to merge back into the whole tree. Dunno, though. [09:25] Can I keep updating the subtree from the main repo? [09:25] (I've never used SPLIT before) [09:26] ie, can pull fetch data from a subdir in a branch? [09:29] spiv, I'm pushing up a new version that makes the change you've suggested. [09:29] very. solwly. [09:30] (well, after I upgrade it. man, isn't that just the gift that keeps on giving?) [09:46] spiv, pushed. === weigon_ is now known as weigon [10:02] I run into a problem on karmic when pushing to LP, http://pastebin.ubuntu.com/337892/ [10:02] it says different rich-root support [10:17] I assume I need to upgrade the LP branch === jelmer_ is now known as jelmer [10:43] TeTeT: right [10:44] TeTeT: generally "bzr upgrade lp:FOO" should Just Work. [10:57] spiv: can I still access the branch from hardy then with the new format? === gdmfsob is now known as mishok13 [11:40] TeTeT: you need bzr 2.0 (or at least 1.18), which I don't think is in hardy's backports yet, but we have a backport in the PPA: https://edge.launchpad.net/~bzr/+archive/ppa [11:42] spiv: ok, so I rather branch on merge on hardy then, so it stays compatible, thanks [11:49] TeTeT: if you create your repo with --pack-0.92, it'll be the same format as that branch on Launchpad [11:51] spiv: I do that for init-repo? [11:58] TeTeT: yep [12:06] spiv: thanks for your help! [12:07] TeTeT: not a problem, glad I could help. [12:19] jml: are you sure you pushed? I don't see any new revisions [12:20] jml: oh, it's stacked on the old, non-rich-root, bzr trunk, so boom: https://code.edge.launchpad.net/~jml/bzr/lp-login-oauth [12:20] jml: I think bzr and launchpad can take equal credit for that snafu ;) === Meths_ is now known as Meths [13:32] jam, jam1, jam*: ping === CardinalXiminez_ is now known as CardinalFang === thunderstruck is now known as gnomefreak [14:47] vila: pong [14:47] sorry, pidgin disconnected and didn't want to reconnect until I restarted it [14:48] bad pidgin :) [14:50] jam: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 is up for windows tests [14:50] ./bzr selftest -s bt.test_osutils.TestTerminal should now pass [14:51] but see cover letter for my requests ;-) [14:51] <__monty__> Is it a good idea to have a hand at some low priority bugs to get more python experience? [14:51] __monty__: sure [14:52] __monty__: sure. The devs here are really good at helping you through the process of getting it included too. [14:52] __monty__: you might look for the "easy" tag [14:52] if people haven't grabbed them all already [14:52] I think there might also be "trivial" ? [14:52] vila: so, one of the primary reasons to use stderr is because progress bars go to ... stderr [14:53] so even if you redirect stdout [14:53] you still would like to know the term width, to draw a progress bar [14:53] <__monty__> Thanks for the quick replies. [14:53] that said, I guess the test suite wants to have stdout width [14:53] which means... it sounds like we should have a flag [14:53] __monty__: I would suggest a trivial tag at first. just to get your first patch in. Then once you get the hang of how to get something in go for something bigger. [14:53] that's what I did at least [14:54] jam: bzr help also needs the terminal width but outputs on stdout... [14:55] and so does log --line [14:55] sure [14:55] though what should those do when redirected to a file? [14:55] log --line, I would probably expect to go full width [14:55] use None and not cut lines [14:55] bzr help... probably we want to keep it wrapped at a reasonable width [14:55] yup [14:55] since otherwise the full help texts becomes super long [14:56] or the text editor wraps it in an ugly way [14:56] long story short, that's what BZR_COLUMNS is for [14:57] to come back to windows, using stderr or stdout shouldn't matter since it should not be called anymore [14:58] you had some tests with and without redirection, how do they behave now ? [14:58] with --subunit and tee IIRC [14:58] vila: but that is an ugly way to do it [14:58] BZR_COLUMNS=20 bzr command foo > [14:58] espec on windows [14:59] where you can't inline it [14:59] set BZR_COLUMNS=40 [14:59] bzr command foo > [14:59] set BZR_COLUMNS= [14:59] I would like to have a better answer than that [14:59] but yes, I'll run the tests [15:00] yeah I know, poolie filed a bug about using -O to set options without polluting the global options namespace. Fom there having some rules to go from env variables to options should filled the gap. At least for things like BZR_PLUGIN_PATH and BZR_COLUMNS [15:01] so you can use say bzr -OBZR_COLUMNS=46 command [15:01] or bzr -OBZR_PLUGIN_PATH=-site selftest \o/ [15:01] vila: test suite passes on windows when run manually and when run redirected [15:01] oops [15:01] spoke too soon [15:02] test_falls_back_to_COLUMNS [15:02] fails [15:02] when redirected [15:02] 42 != None [15:03] vila: you have: getattr(sys.stdout, 'isatty', None) before the COLUMNS check [15:03] so I think that test would fail on Linux when redirected as well [15:03] yeah, so that test is bogus [15:04] COLUMNS makes sense only for a tty [15:04] vila: as said before, stderr may be a tty even if stdout isn't [15:05] ... :) [15:05] hmm [15:06] I;m tempted to reply ESCOPE :-) === vds1 is now known as vds [15:08] so, I want my test suite to pass [15:09] I don't really care about the answer here [15:09] what we've had has been just fine for me for a long time [15:09] jam: pushing a fix [15:09] I would be a little concerned about fixing something that isn't broken [15:09] but apparently for others it is ? [15:10] well, the main problem was pagers and the lack of overriding solution [15:10] I think the proposed fix make things clearer [15:11] to address the stdout/stderr I think we need yet another pass on all uses and disambiguate the API by explicitly requesting for either stdout or stderr, the windows heuristic sounds brittle otherwise [15:12] what if stderr is redirected and not stdout ? [15:12] vila: right, so 'bzr log --line | less' is different than 'bzr log --line > file', but I don't think there is a way to detect the difference [15:12] vila: unlikely to have stderr redirected and not stdout [15:12] and if it does, then progress bars do crazy things [15:12] OMFG how did they implement pipes 8-/ [15:13] jam: never say unlikely on IRC, fullermd is never far away.... [15:13] we've had similar issues with encodings based on "| less" versus "> file" [15:13] because on windows [15:13] standard file encoding [15:13] != standard terminal encoding [15:13] Error: I am only a bot, please don't think I'm intelligent :) [15:13] which is crazy [15:13] oh, and it isn't filesystemencoding either [15:13] !triggers ubottu ? [15:13] Error: I am only a bot, please don't think I'm intelligent :) [15:14] vila: yeah [15:14] so you can say !paste [15:14] but only at the beginning [15:14] !paste [15:14] For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic [15:14] !pastebinit [15:14] pastebinit is the command-line equivelent of !pastebin - Command output, or other text can be redirected to pastebinit, which then reports an URL containing the output - To use pastebinit, install the « pastebinit » package from a package manager - Simple usage: command | pastebinit [15:14] interesting [15:14] hard to parse "pastebin it" [15:14] I thought it was "pastebin init" at first [15:14] anyway [15:15] vila: do what feels good to get things passing [15:15] we've probably spent far too much time versus the utility already [15:15] (my feeling is, we're going to get it wrong, probably fairly often. whatever decision we choose) [15:15] jam: agreed, fix pushed, can you check it works for you [15:16] vila: all tests pass [15:16] on the other hand, people have complained regularly about the lack of pager support, now we have *some* support [15:17] jam: Courtesy url for votes: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 [15:17] :D [15:17] you assigned bzr core devs on #154129 , what do you mean by that ? [15:19] we all worked together on implementing 2a [15:19] so we all get credit [15:19] bug #154129 [15:19] Launchpad bug 154129 in bzr "pack should recompress objects, optimise layout, etc" [Medium,Fix released] https://launchpad.net/bugs/154129 [15:19] well, at least I didn't feel I should be the only one getting credit, and once the number is greater than 1, there isn't a clear value to put three [15:19] jam: nevermind, I thought it was still open [15:23] vila: merge approved, witha bit of a mini rant for posterity [15:23] lol [15:25] jam: good summary.... I'll put https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 in some commit message so you'll get true posterity :^) [15:26] <__monty__> Would this: https://bugs.launchpad.net/bzr/+bug/257170 be a good bug for a beginner? [15:26] Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed] [15:30] Hmm? Somebody summon me with an 'unlikely'? :p [15:30] __monty__: probably. I think it is already slightly fixed when there is an exception, but it probably would be good to write out "bzrlib.__version__" on startup always. [15:31] fullermd: your summoning time has gotten slow recently :) [15:31] well, today at least [15:31] <__monty__> jam: By startup you mean? [15:31] Well, you've never met me, so you'll have to take my word for it, but TRUST me; I NEED my beauty sleep :p [15:32] fullermd: sleep is for ? [15:32] __monty__: the bug is that when the bzr process starts, we log the command line arguments, but we don't put version info into the log file [15:32] fullermd: sort of a Shrek1 sort of thing? (by night one way, by day another) [15:33] <__monty__> jam: So it doesn't have anything to do with bzr log ? [15:33] __monty__: correct [15:33] this is about .bzr.log [15:33] not 'bzr log' [15:33] Of course, in this case I won't contest the unlikely. Being a csh user, I don't get to adjust stderr without touching stdout :p [15:35] <__monty__> To work on bzr bugs, which source release should I get? === beuno is now known as beuno-lunch [15:49]