[00:01]  * poolie looks
[00:13] <poolie> ok
[00:25] <mwhudson> the bzr-builder "parser" is a little sad making
[00:30] <james_w> oi!
[00:31] <mwhudson> james_w: hi :-)
[00:31] <mwhudson> it'
[00:31] <james_w> hi mwhudson :-)
[00:32] <james_w> output from "bzr merge":
[00:32] <james_w> deleted misc
[00:32] <james_w> ...
[00:32] <james_w> Path conflict: misc / misc
[00:32] <james_w> "bzr st":
[00:32] <james_w> removed:
[00:32] <james_w>   misc/
[00:32] <james_w> ...
[00:32] <james_w> conflicts:
[00:32] <james_w>   Path conflict: misc / misc
[00:33] <james_w> ls misc*:
[00:33] <james_w> No matches: misc*
[00:33] <james_w> what sort of conflict is that?
[00:35] <spiv> james_w: exciting?  confusing?  There are lots of adjectives ;)
[00:35] <james_w> 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] <james_w> It's not inexperience that led to that implementation
[00:36] <james_w> spiv: I'd say both of those apply
[00:36] <james_w> I've no idea how to resolve it, or even why I thinks I need to
[00:36] <mwhudson> james_w: it would be nice if there was a grammar for recipes i think
[00:37] <james_w> yes
[00:37] <mwhudson> it's not that the current parser is bad, but it's a bit of a blob
[00:37] <mwhudson> separate lexing and parsing might be nice
[00:37] <james_w> and then it would be nice if the parser was generated from that, so it was confirmed to be nice
[00:37] <mwhudson> but maybe that's ott for something simple
[00:38] <mwhudson> james_w: my use case is wanting to rewrite the branch references in a recipe
[00:38] <james_w> lexing is hard in this case
[00:39] <mwhudson> i guess line.split() is a fair approximation of what's possible actually :)
[00:40] <james_w> yes
[00:40] <james_w> plus, "bzr tag 'a tag'" would lead to some issues
[00:40] <james_w> and spaces in URIs may be a bit of a pain with bzrlib
[00:41] <mwhudson> %20 ftw i guess
[00:41] <mwhudson> but you can't put a space in the url of a branch on launchpad so...
[00:42] <james_w> true
[00:42] <james_w> the issue is that bzr transports take strings, and there's no way to tell if whether it is escaped or not
[00:44] <james_w> e.g. https://bugs.edge.launchpad.net/bzrtools/+bug/310631
[00:45] <mwhudson> james_w: i think bzrlib generally assumes that urls are escaped
[00:46] <mwhudson> so that looks like a straight up bug
[00:53] <mwhudson> hm, i guess you're right, it's a bit muddled
[00:55] <james_w> bzrtools is doing urlutils.normalize_url() on the path, which might be wrong
[00:55] <james_w> not doing it might give other problems though
[00:56] <mwhudson> no, it's the split path and get that's messing things up
[00:56] <mwhudson> >>> urlutils.normalize_url('http://python.org/?arg=value')
[00:56] <mwhudson> 'http://python.org/?arg=value'
[00:57] <james_w> ah
[00:58] <james_w> that bug's all over the place in my code then
[00:58] <mwhudson> well
[00:58] <mwhudson> i don't know what the right fix is
[00:59] <mwhudson> i guess httptransport's .get() is broken
[00:59] <mwhudson> but fixing it might break other stuff
[01:02] <mwhudson> james_w: bzrlib.transport.Transport._unsplit_url says in the docstring
[01:03] <mwhudson>         Build the full URL for the given already URL encoded path.
[01:03] <mwhudson> but then escapes the path anyway
[02:26] <lifeless> jam: https://ec2-sshd.dev.java.net/
[02:46] <mwhudson> james_w: still here?
[02:47] <james_w> yep
[02:49] <mwhudson> james_w: where in the world are you at the moment? ;)
[02:49] <james_w> home
[02:49] <james_w> physically, if not temporally.
[02:49] <mwhudson> yikes
[02:49] <mwhudson> james_w: we have this need to rewrite the branch urls in a recipe
[02:50] <james_w> yes
[02:50] <mwhudson> 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] <mwhudson> james_w: i think it makes sense for this code to be part of bzr-builder
[02:51] <james_w> yep, in some form
[02:52] <mwhudson> james_w: i'm not sure whether the input to this functionality should be the recipe text or the BaseRecipeBranch
[02:52] <mwhudson> 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] <james_w> not sure offhand
[02:53] <james_w> it would be possible to preserve that
[02:53] <james_w> fugly, but possible
[02:53] <mwhudson> unless you make the parser smarter
[02:53] <mwhudson> yeah
[02:53] <james_w> preserving comments is probably something we should do anyway
[02:54] <mwhudson> 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] <mwhudson> james_w: preserving comments in the manifest, you mean?
[02:54] <james_w> yeah
[02:54] <mwhudson> ok
[02:54] <mwhudson> well that's an argument towards making my changes more "core" and less of a parallel hack i guess
[02:55] <mwhudson> which is probably a good thing
[02:55] <james_w> yeah
[02:56] <james_w> I dread the code to preserve though
[02:56] <james_w> I think we might need to change the model to make it palatable
[02:56] <james_w> or maybe not too much
[02:57] <mwhudson> it's not clear to me where you'd put comments in the model
[02:58] <james_w> perhaps a new instruction that's a null, but stores the comment?
[03:02] <mwhudson> james_w: i guess
[03:03] <mwhudson> james_w: edge cases galore though
[03:03] <mwhudson> james_w: spot the difference! http://pastebin.ubuntu.com/337738/
[03:04] <james_w> them the rules! :-)
[03:04] <spiv> mwhudson: makes perfect sense ;)
[03:04] <james_w> we could fix that case if you want to file a bug though
[03:05] <james_w> try putting 3 spaces in the middle line though :-)
[03:05] <mwhudson> oh and you can't have comments at the end of significant lines
[03:06] <mwhudson> james_w: i noticed the mandatory two space indent, at least that gets around some of python's complexity here :)
[03:06] <james_w> that's one of Mark's :-)
[03:06] <mwhudson> heh heh
[03:09] <mwhudson> james_w: is not being able to put comments at the end of a line a feature?
[03:10] <mwhudson> it leads to some slightly strange error messages
[03:10] <james_w> I don't think it is
[03:10] <mwhudson> ok
[03:11]  * mwhudson gets his bug filing hat on
[03:12] <mwhudson> james_w: https://bugs.edge.launchpad.net/bzr-builder/+bug/487174 reminds me to ask you what the branch ids are for
[03:15] <james_w> revno:<id>
[03:15] <james_w> and derivation when we implement that
[03:19] <mwhudson> james_w: oh, in the debversion?
[03:19] <james_w> yeah
[03:20] <mwhudson> makes sense
[03:22] <mwhudson> james_w: i filed three bugs, i guess you got emailed about them
[03:23] <james_w> I do, thanks
[03:24] <treeform1r> it keeps asking me for password how can i unbind
[03:24] <treeform1r> if it says i am unbound?
[03:26] <treeform1r> i type "bzr unbind" - it asks me for passwrod - why?
[03:26] <treeform1r> i type it in
[03:26] <treeform1r> it says i am unbound allready
[03:26] <treeform1r> how can i just work locally?
[03:29] <mwhudson> james_w: i worry a bit about the interaction of # and the run command
[03:29] <mwhudson> treeform1r: what does bzr info say?
[03:47]  * igc lunch
[05:00] <gbbzr> 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] <poolie> gbbzr: no, but you could ask on the list
[05:27] <poolie> abadger i think is involved with it but he's not here now
[05:36] <jml> hello
[05:37] <jml> does Gordon Tyler hang out on IRC?
[05:39] <spiv> jml: I think he does, sometimes
[05:40] <spiv> jml: nick is dOxxx I think, maybe +/- an x
[05:41] <jml> spiv, thanks.
[06:30] <bignose> I see references to “No handlers could be found for logger "bzr"” in various search results
[06:30] <bignose> but no real clue as to why it would suddenly start happening.
[06:31] <bignose> 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] <spiv> bignose: perhaps because bzr couldn't open ~/.bzr.log?
[06:37] <spiv> (or wherever 'bzr --version' says the log file ought to be)
[06:38] <bignose> argh
[06:38] <spiv> bignose: IIRC a relatively common cause is 'sudo bzr'
[06:38] <bignose> why does that file occasionally get owned by root
[06:38] <bignose> well, grumble mumble bumble.
[06:39] <spiv> 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] <bignose> perhaps a FAQ entry would be good on that.
[06:39] <spiv> Well, I suppose bzr could emit a clearer warning.
[06:39] <bignose> yes, that too.
[06:40] <bignose> it would be good to say explicitly that Bazaar doesn't have the permission it needs to its own log file.
[06:46] <spm> 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] <spiv> spm: heh
[06:48]  * spm emails losas with this fine tidbit of info
[06:50] <spiv> It's bug 354843 FWIW
[06:50] <spiv> (And I just marked two other bugs as dupes of that!)
[06:56] <spiv> Oh hmm we have two 'Critical' bugs, I hadn't noticed that.
[07:28] <jml> I really, really want to depend on launchpadlib.uris
[07:36] <spiv> jml: sounds a bit like an ad campaign for a cleaning product... "launchpadlib... you can depend on it!"
[07:36] <jml> heh
[07:37] <vila> hi all
[07:39] <vila> 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] <vila> jml: ECONTEXT, I'm sure launchpadlib.uris is great why advertising it here ? :D
[07:41] <vila> s/great why/great BUT why/
[07:42] <vila> Here I go, ruining my first joke of the day with stupid typos... not even a good joke...
[07:42] <jml> vila, because I could delete code from bzrlib.plugins.launchpad
[07:42] <vila> ha! And you fear the consequences :)
[07:42] <jml> vila, well, bzr can't have a hard dep on launchpadlib, realistically
[07:42] <vila> yeah, but I thought the plan was to make it a soft one
[07:43] <jml> vila, also, launchpadlib.uris was added to launchpadlib mere hours _after_ the last version of launchpadlib was released
[07:43] <vila> LOL
[07:44] <vila> Gimme the new toys !
[07:44] <jml> it was released last in October
[07:44] <vila> argh
[07:44] <jml> there's been a whole release of Ubuntu since then.
[07:45] <vila> jml: don't get me wrong, there are very good reasons to use the new toys :)
[07:47] <MvG> 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] <spiv> MvG: I guess doing g = repo.get_graph();  heads = g.heads([revA, revB]) gives you that info with reasonable caching.
[07:53] <spiv> 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] <MvG> I think so, too.
[07:54] <MvG> 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] <spiv> MvG: so what I'd do then is rely on _revision_relations and file a bug about promoting it
[07:54] <spiv> Heh.
[07:54] <spiv> Well, it's possible that it already does and I just haven't thought of it :)
[07:54] <spiv> If it does, then presumably I can remove _revision_relations and cut down on duplicated code ;)
[07:55] <spiv> Hmm, I think it probably makes sense a method on Graph.
[07:56] <spiv> I suppose Graph.find_difference sort of gives you the same thing.
[07:57] <spiv> Dunno what the performance of that is lie.
[07:57] <spiv> like, rather.
[07:58] <spiv> There's Graph.is_ancestor, which gives you part of the info.
[07:58] <MvG> 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] <spiv> But no equivalent method that I can see.
[07:59] <MvG> 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] <spiv> _revision_relations is also implemented in terms of heads.
[07:59] <MvG> Yes, that's how I found it.
[07:59] <spiv> But only makes a single heads call, of course.
[08:00] <spiv> 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] <MvG> 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] <spiv> MvG: Repository.get_graph() should already be caching, so I don't think there's a practical difference
[08:13] <MvG> Repository.get_graph() does cache the graph itself, while Repository._heads does cache results from heads requests directly.
[08:13] <spiv> Well, I suppose __heads is specially optimised for heads() lookups.
[08:14] <spiv> But if it's that useful I would think it should be cached on graph rather than the repository.
[08:15] <spiv> MvG: Actually Repository doesn't have __heads/_heads, you're looking at CommitBuilder I think
[08:16] <spiv> 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] <MvG> spiv: You're right. I guess I'm too used to Java, with its one class per file paradigm.
[08:18] <jml> 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] <MvG> 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] <spiv> MvG: right
[08:18] <jml> I thought plugins were loaded lazily
[08:19] <jml> if they aren't, how can I do a conditional lazy import?
[08:19] <spiv> 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] <spiv> jml: they can't be; otherwise how can a plugin e.g. decorate a builtin command the way bzr-loom does?
[08:19] <spiv> jml: however, plugins can and should use lazy_import themselves
[08:20] <jml> spiv, ok. that's good to know.
[08:20] <jml> spiv, how do I do a lazy import that behaves like the one in the patch?
[08:20] <spiv> 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] <spiv> jml: so, you want lp-mirror to only exist if the dependency is available?
[08:21] <spiv> jml: why not make it always exist, but give an error if the dependency is missing?
[08:22] <spiv> jml: I think that might be a nicer UI too, it seems more discoverable to me
[08:22] <jml> spiv, I guess I could do that.
[08:22] <spiv> "Why don't I have lp-mirror, I have the launchpad plugin!"
[08:22] <spiv> 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] <jml> spiv, I can imagine it being a little confusing to have lots of available commands that you can't actually use.
[08:23] <spiv> Well, let's worry about that when we have lots rather than one?
[08:23]  * igc dinner
[08:24] <spiv> I can imagine making some infrastructure for that, maybe provide something like "bzr plugins --check-deps" that plugins can hook into?
[08:24] <spiv> But we already have this situation with e.g. SFTP support without causing much drama.
[08:25] <spiv> (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] <spiv> 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] <jml> OK
[08:27] <spiv> (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] <spiv> jml: I'll add a brief note about my opinion to the review for posterity
[08:31] <MvG> 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] <spiv> 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] <spiv> MvG: so the comparison in that case is basically just a pointer comparison
[08:33] <spiv> MvG: I'd be happy have module-global constants for those strings, I think.
[08:33] <spiv> 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] <MvG> Probably true, yes.
[08:34] <spiv> MvG: If you measure a performance problem, I'd be very happy to look at the measurement and figure out improvements, though :)
[08:34] <spiv> MvG: but I strongly advise against micro-optimisations that impact code clarity without evidence that they'll have a significant effect.
[08:35] <MvG> Agreed. Didn't know about Python cheaply comparing such things.
[08:36] <MvG> 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] <spiv> MvG: yes
[08:37] <spiv> MvG: I've no idea why I never noticed that before :)
[08:39] <spiv> 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] <spiv> MvG: I'll happily chat about CPython implementation trivia sometime if you like, but not tonight :)
[08:42] <MvG> 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] <spiv> MvG: CONSTANT = 'value'
[08:49] <spiv> MvG: rather than: variable = 'value' :)
[08:49] <MvG> But python doesn't enforce constantness on these, does it?
[08:49] <spiv> No, but it doesn't enforce constantness on anything, more or less :)
[08:50] <spiv> Except the evaluation of 1+1, and I've seen an extension module to change that ;)
[08:50] <MvG> 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] <spiv> MvG: thanks!
[09:14] <sjamaan> I'd like to make a checkout (or branch) of only a subdirectory in a repo. Is that possible?
[09:17] <MvG> 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] <MvG> 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] <sjamaan> Can I keep updating the subtree from the main repo?
[09:25] <sjamaan> (I've never used SPLIT before)
[09:26] <sjamaan> ie, can pull fetch data from a subdir in a branch?
[09:29] <jml> spiv, I'm pushing up a new version that makes the change you've suggested.
[09:29] <jml> very. solwly.
[09:30] <jml> (well, after I upgrade it. man, isn't that just the gift that keeps on giving?)
[09:46] <jml> spiv, pushed.
[10:02] <TeTeT> I run into a problem on karmic when pushing to LP, http://pastebin.ubuntu.com/337892/
[10:02] <TeTeT> it says different rich-root support
[10:17] <TeTeT> I assume I need to upgrade the LP branch
[10:43] <spiv> TeTeT: right
[10:44] <spiv> TeTeT: generally "bzr upgrade lp:FOO" should Just Work.
[10:57] <TeTeT> spiv: can I still access the branch from hardy then with the new format?
[11:40] <spiv> 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] <TeTeT> spiv: ok, so I rather branch on merge on hardy then, so it stays compatible, thanks
[11:49] <spiv> TeTeT: if you create your repo with --pack-0.92, it'll be the same format as that branch on Launchpad
[11:51] <TeTeT> spiv: I do that for init-repo?
[11:58] <spiv> TeTeT: yep
[12:06] <TeTeT> spiv: thanks for your help!
[12:07] <spiv> TeTeT: not a problem, glad I could help.
[12:19] <spiv> jml: are you sure you pushed?  I don't see any new revisions
[12:20] <spiv> 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] <spiv> jml: I think bzr and launchpad can take equal credit for that snafu ;)
[13:32] <vila> jam, jam1, jam*: ping
[14:47] <jam> vila: pong
[14:47] <jam> sorry, pidgin disconnected and didn't want to reconnect until I restarted it
[14:48] <vila> bad pidgin :)
[14:50] <vila> jam: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858 is up for windows tests
[14:50] <vila> ./bzr selftest -s bt.test_osutils.TestTerminal should now pass
[14:51] <vila> 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] <vila> __monty__: sure
[14:52] <rubbs> __monty__: sure. The devs here are really good at helping you through the process of getting it included too.
[14:52] <jam> __monty__: you might look for the "easy" tag
[14:52] <jam> if people haven't grabbed them all already
[14:52] <jam> I think there might also be "trivial" ?
[14:52] <jam> vila: so, one of the primary reasons to use stderr is because progress bars go to ... stderr
[14:53] <jam> so even if you redirect stdout
[14:53] <jam> you still would like to know the term width, to draw a progress bar
[14:53] <__monty__> Thanks for the quick replies.
[14:53] <jam> that said, I guess the test suite wants to have stdout width
[14:53] <jam> which means... it sounds like we should have a flag
[14:53] <rubbs> __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] <rubbs> that's what I did at least
[14:54] <vila> jam: bzr help also needs the terminal width but outputs on stdout...
[14:55] <vila> and so does log --line
[14:55] <jam> sure
[14:55] <jam> though what should those do when redirected to a file?
[14:55] <jam> log --line, I would probably expect to go full width
[14:55] <vila> use None and not cut lines
[14:55] <jam> bzr help... probably we want to keep it wrapped at a reasonable width
[14:55] <vila> yup
[14:55] <jam> since otherwise the full help texts becomes super long
[14:56] <jam> or the text editor wraps it in an ugly way
[14:56] <vila> long story short, that's what BZR_COLUMNS is for
[14:57] <vila> to come back to windows, using stderr or stdout shouldn't matter since it should not be called anymore
[14:58] <vila> you had some tests with and without redirection, how do they behave now ?
[14:58] <vila> with --subunit and tee IIRC
[14:58] <jam> vila: but that is an ugly way to do it
[14:58] <jam> BZR_COLUMNS=20 bzr command foo >
[14:58] <jam> espec on windows
[14:59] <jam> where you can't inline it
[14:59] <jam> set BZR_COLUMNS=40
[14:59] <jam> bzr command foo >
[14:59] <jam> set BZR_COLUMNS=
[14:59] <jam> I would like to have a better answer than that
[14:59] <jam> but yes, I'll run the tests
[15:00] <vila> 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] <vila> so you can use say bzr -OBZR_COLUMNS=46 command
[15:01] <vila> or bzr -OBZR_PLUGIN_PATH=-site selftest \o/
[15:01] <jam> vila: test suite passes on windows when run manually and when run redirected
[15:01] <jam> oops
[15:01] <jam> spoke too soon
[15:02] <jam> test_falls_back_to_COLUMNS
[15:02] <jam> fails
[15:02] <jam> when redirected
[15:02] <jam> 42 != None
[15:03] <jam> vila: you have: getattr(sys.stdout, 'isatty', None) before the COLUMNS check
[15:03] <jam> so I think that test would fail on Linux when redirected as well
[15:03] <vila> yeah, so that test is bogus
[15:04] <vila> COLUMNS makes sense only for a tty
[15:04] <jam> vila: as said before, stderr may be a tty even if stdout isn't
[15:05] <jam> ... :)
[15:05] <vila> hmm
[15:06] <vila> I;m tempted to reply ESCOPE :-)
[15:08] <jam> so, I want my test suite to pass
[15:09] <jam> I don't really care about the answer here
[15:09] <jam> what we've had has been just fine for me for a long time
[15:09] <vila> jam: pushing a fix
[15:09] <jam> I would be a little concerned about fixing something that isn't broken
[15:09] <jam> but apparently for others it is ?
[15:10] <vila> well, the main problem was pagers and the lack of overriding solution
[15:10] <vila> I think the proposed fix make things clearer
[15:11] <vila> 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] <vila> what if stderr is redirected and not stdout ?
[15:12] <jam> 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] <jam> vila: unlikely to have stderr redirected and not stdout
[15:12] <jam> and if it does, then progress bars do crazy things
[15:12] <vila> OMFG how did they implement pipes 8-/
[15:13] <vila> jam: never say unlikely on IRC, fullermd is never far away....
[15:13] <jam> we've had similar issues with encodings based on "| less" versus "> file"
[15:13] <jam> because on windows
[15:13] <jam> standard file encoding
[15:13] <jam> != standard terminal encoding
[15:13] <jam> which is crazy
[15:13] <jam> oh, and it isn't filesystemencoding either
[15:13] <vila> !triggers ubottu ?
[15:14] <jam> vila: yeah
[15:14] <jam> so you can say !paste
[15:14] <jam> but only at the beginning
[15:14] <jam> !paste
[15:14] <jam> !pastebinit
[15:14] <jam> interesting
[15:14] <jam> hard to parse "pastebin it"
[15:14] <jam> I thought it was "pastebin init" at first
[15:14] <jam> anyway
[15:15] <jam> vila: do what feels good to get things passing
[15:15] <jam> we've probably spent far too much time versus the utility already
[15:15] <jam> (my feeling is, we're going to get it wrong, probably fairly often. whatever decision we choose)
[15:15] <vila> jam: agreed, fix pushed, can you check it works for you
[15:16] <jam> vila: all tests pass
[15:16] <vila> on the other hand, people have complained regularly about the lack of pager support, now we have *some* support
[15:17] <vila> jam: Courtesy url for votes: https://code.edge.launchpad.net/~vila/bzr/353370-notty-no-term-width/+merge/15858
[15:17] <vila> :D
[15:17] <vila> you assigned bzr core devs on #154129 , what do you mean by that ?
[15:19] <jam> we all worked together on implementing 2a
[15:19] <jam> so we all get credit
[15:19] <jam> bug #154129
[15:19] <jam> 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] <vila> jam: nevermind, I thought it was still open
[15:23] <jam> vila: merge approved, witha bit of a mini rant for posterity
[15:23] <vila> lol
[15:25] <vila> 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:30] <fullermd> Hmm?  Somebody summon me with an 'unlikely'?   :p
[15:30] <jam> __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] <jam> fullermd: your summoning time has gotten slow recently :)
[15:31] <jam> well, today at least
[15:31] <__monty__> jam: By startup you mean?
[15:31] <fullermd> 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] <vila> fullermd: sleep  is for ?
[15:32] <jam> __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] <jam> 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] <jam> __monty__: correct
[15:33] <jam> this is about .bzr.log
[15:33] <jam> not 'bzr log'
[15:33] <fullermd> 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?
[15:49] <Pilky> ouch: http://www.reddit.com/r/programming/comments/acsad/bazaar_blows_goats/
[15:50] <Pilky> I sort of agree with the gist of his launchpad comment and the cold start slowness, but the rest of it sounds like "It isn't what I'm used to, waaah"
[16:32] <jam> fullermd: why is that the case on csh?
[16:38] <__monty__> Should I get the stable or the developer release of the source code to work on bugs?
[16:43] <jelmer> __monty__, the code from bzr.dev ideally
[16:45] <fullermd> jam: You mean historically?  Dunno.  Just how it is.
[16:45] <jam> fullermd: is it just that the syntax doesn't let you?
[16:45] <jam> __monty__: for this, the stable code would be ok, but bzr.dev is fine, too
[16:45] <fullermd> Oh, yes.  It's one of the standard csh-whynot-isms.
[16:46] <fullermd> You can dup it onto stdout, and that's about it.
[16:47] <NfNitLoop> so... I seem to get the impression that bzr-svn stores more metadata than git-svn when you push back into the upstream svn repo...
[16:48] <NfNitLoop> is that true?  Anyone know off-hand?
[16:49] <NfNitLoop> Ok, I'll ask Google. :)
[16:51] <jelmer> NfNitLoop: yes, that's true - bzr has more metadata than git
[16:52] <NfNitLoop> I know bzr stores the non-linear history metadata as svn properties...   is that what's missing in git?
[16:57] <NfNitLoop> It may be a bit academic.  If git-svn lets me work with our SVN repo that bzr-svn won't (because at some point in its history there was a file with backslashes in its name)...  I may just suffer through using git.
[16:59] <Tak> bzr-git < git-svn < svn ? ;-P
[17:00] <NfNitLoop> ya, ew.
[17:00] <NfNitLoop> :p
[17:00] <jelmer> NfNitLoop: That's one thing
[17:00] <jelmer> NfNitLoop: Other things are: file ids, revision ids and revision properties (none of which git has)
[17:00] <Pilky> Tak: why not throw hg in there and do bzr-hg < hg-git < git-svn < svn :p
[17:01] <NfNitLoop> ah, I knew git didn't do file IDs...  it doesn't even store the revision ID!?
[17:01] <NfNitLoop> that seems odd.
[17:01] <Pilky> Tak: if you tried hard enough you might be able to get cvs in there somewhere
[17:01] <fullermd> git revision id's are entirely derivable from the contents of the revision.
[17:01] <NfNitLoop> so if you then do an update you might start getting conflicts with branches that have already merged the changes?
[17:01] <NfNitLoop> aaah.
[17:01] <NfNitLoop> ok, that's fine then.
[17:01] <jelmer> NfNitLoop: I'm not sure what the status of backslash support is
[17:02] <NfNitLoop> in git?  I guess I'll see when git gets to that revision. :p
[17:02] <Tak> Pilky: I guess that would depend on whether hg or git have a cvs wrapper
[17:03] <Tak> speaking of which, I pulled down someone's inadvertent commit of an RCS dir to our svn repo the other day
[17:03] <jelmer> NfNitLoop: in bzr
[17:03] <jelmer> NfNitLoop, bzr-svn supports backslashes fine
[17:03] <NfNitLoop> jelmer: ah, I'm subscribed to the bug about it.  haven't seen any traffic lately.
[17:58] <__monty__> Is there a bug which you would advise for a newb?
[18:09] <jelmer> __monty__: try looking for bugs triaged trivial in launchpad
[18:10] <__monty__> Any of them?
[18:10] <__monty__> Such as: https://bugs.launchpad.net/bzr/+bug/239523
[18:12] <jelmer> yeah, all bugs tag trivial *should* be doable for people looking to contribute to bzr for the first time
[18:12] <jelmer> feel free to ask for mentoring here or on the mailing list
[18:13] <RenatoSilva> verterok: hi
[18:13] <__monty__> What are the responsibilities of a mentor?
[18:19] <jam> __monty__: it isn't quite an official thing. Just that you can ask for help/questions and we'll try to help you
[18:19] <__monty__> Oh ok.
[18:30] <RenatoSilva> verterok: ok np :)
[19:19] <jam> __monty__: I should also mention our PatchPilot program: http://wiki.bazaar.canonical.com/PatchPilot
[19:19] <jam> Which is where we have people specifically working on helping people land their patches
[19:47] <johnjosephbachir> hello
[19:47] <__monty__> hi
[19:48] <johnjosephbachir> how do i make a new remote branch? this equivalent from subversion does not work: bzr branch http://example.com/foo http://example.com/bar
[19:48] <johnjosephbachir> do i make the new branch locally and then push it?
[19:48] <beuno> johnjosephbachir, yes
[19:48] <johnjosephbachir> there isn't a more direct way?
[19:49] <beuno> johnjosephbachir, bzr init REMOTE_LOCATION
[19:49] <beuno> but you can't do it via http
[19:49] <beuno> you will need ssh
[19:49] <johnjosephbachir> how about webdav?
[19:49] <johnjosephbachir> bueno what would be the command for ssh?
[19:52] <johnjosephbachir> okay, i just did it the push-from-local way, and it worked in seconds -- so i guess bzr was smart about using the remote repo, hoorary
[19:52] <johnjosephbachir> sorry for the newb question
[19:55] <rubbs> johnjosephbachir: don't be sorry for newb questions. If anything it gives those of us on the doc team something to consider
[19:55] <rubbs> ;)
[19:55] <johnjosephbachir> thanks
[19:55] <rubbs> np
[20:09] <jml> spiv, I don't supposed you fixed it?
[20:43] <dOxxx> *sigh* cable outages suck :P
[21:08] <rubbs> dOxxx: yes, cable outages do suck. What caused yours?
[21:08] <dOxxx> we've had a bit of a winter storm here, so I guess it's causing trouble with the wires
[21:08] <dOxxx> don't know for certain though
[21:09] <rubbs> ah, you in the midwest?
[21:09] <rubbs> I used to live in Iowa
[21:09] <dOxxx> nope, Toronto
[21:10] <rubbs> ah, gotcha.
[21:10] <rubbs> I live in Ohio now so we're about to get one too.
[21:12] <dOxxx> Enjoy! :)
[21:12] <dOxxx> hmmm... might be cutting out again soon
[21:13] <dOxxx> ominous pauses
[21:14] <rubbs> haha
[21:15] <fullermd> Winter...   yeah, I remember hearing about that, years ago...
[21:49] <phinze> ack! my shelf! http://gist.github.com/252861
[21:50] <phinze> hmm looks like it's bug 389674
[21:51] <phinze> This is because the conflict handling code has not been fully updated to avoid using Tree.inventory. -- abentley
[21:54] <phinze> i'm looking at the shelf-1 file, which is in 'Bazaar pack format 1'
[21:55] <phinze> i feel like i know where the evil conflict is, but i don't know how many lines to delete :P
[21:58] <phinze> eh, feels like i'm about 10 minutes short of finding docs on the format, but it's small enough that it's faster for me to manually re-apply the changes
[21:59] <phinze> sure
[21:59] <phinze> that worked
[22:11] <jelmer> what exactly are the release plans for bzr 2.1? Should lucid have 2.1?
[22:11] <spiv> jml: at 11pm?  No :)
[22:11] <jml> spiv, what are you replying to, excatly?
[22:11] <spiv> jml: <jml> spiv, I don't supposed you fixed it?
[22:12] <jml> spiv, oh ok. I wasn't online at 11pm, so I was a bit confused.
[22:28] <poolie> hi all
[22:43] <mdt> I'd like to back up my repositories (weekly using a cron script) to a remote backup service.   Anybody know how to do this?  With CVS I just copied the files in the central repository to the remote server using rsync.
[22:45] <gioele> mdt: you can do that with bzr as well
[22:46] <mdt> New to Bazaar so don't rly know how/where data is kept, even
[22:46] <gioele> just rsync the .bzr directory of the repository
[22:47] <gioele> I have a repository at /srv/backup/
[22:47] <gioele> that directory contains a .bzr sub directory
[22:49] <gioele> I use rsync --archive --partial --partial-dir=.rsync-partial --delete-delay --progress -i /srv/backup/ remote:~/backup-bzr
[22:49] <fijal> hi
[22:49] <fijal> I'm looking for bzr benchmarks
[22:49] <poolie> fijal: http://bazaarvcs.wordpress.com/tag/benchmark/
[22:49] <poolie> to start with
[22:50] <fijal> er
[22:50] <fijal> ok
[22:50] <fijal> let's be more specific
[22:50] <fijal> I look for bzr performance benchmarks
[22:50] <spiv> poolie: fijal is a pypy dev, I think
[22:50] <fijal> correct
[22:50] <poolie> you want to test bzr under pypy vs elsewhere?
[22:50] <fijal> yop
[22:51] <poolie> check out https://launchpad.net/bzr-usertest
[22:51] <spiv> And thus wants to make C extensions for performance obsolete ;)
[22:51] <poolie> which runs various macrobenchmarks
[22:51] <poolie> ooh, welcome :)
[22:51] <fijal> does it come with "a standard repository"?
[22:51] <poolie> there are some in-tree microbenchmarks but they tend to rot
[22:51] <poolie> fijal: no, it runs on your choice of repository
[22:51] <poolie> since the test data would be large
[22:51] <poolie> possibly we should put some snapshots in its download files
[22:51] <fijal> can I have one large repository please :)
[22:52] <spiv> fijal: lp:mysql :)
[22:52] <poolie> bzr branch lp:mysql
[22:52] <poolie> :)
[22:52] <fijal> ok
[22:52] <poolie> hi spiv too
[22:52] <spiv> Good morning :)
[22:52] <fijal> well, it's sort of hard to look for pure-python benchmarks
[22:52] <fijal> which are *not* template languages
[22:52] <spiv> Haha
[22:52] <spiv> I can believe that :)
[22:53] <mdt> so does the .bzr directory contain all the info required to reproduce all the files in my project?  I mean if I simply copy that dir recursively onto a brand new machine somewhere I'll be able to check out my project from it?
[22:53] <fijal> for example mostly everybody moved to C
[22:53] <fijal> side question - what's the ratio of oldstyle vs newstyle classes in bzr?
[22:53] <fijal> (I'm too lazy to check)
[22:53] <spiv> Practically all new.
[22:54] <fijal> good
[22:54] <fijal> this is completely unlike twisted
[22:54] <spiv> Indeed :)
[22:54] <fijal> which has practically all old
[22:54] <spiv> We've depended on python >= 2.4 since bzr began.
[22:54] <spiv> Twisted didn't have that luxury :)
[22:55] <fijal> right
[22:55] <spiv> (glyph just cited some 1.5.2 docs at me in a recent review of a patch I just did for Twisted!)
[22:56] <mdt> @gioele ty
[22:57] <igc> morning
[22:58] <fijal> ok
[22:58] <fijal> since it
[22:58] <fijal> 's midnight I'll actually go to bed
[22:59] <fijal> I'll try to make some benchmarks tomorrow then
[22:59] <gioele> just wondering, how long does it take to branch lp:mysql?
[23:04] <spiv> fijal: oh, lp:mysql-server is actually the large branch I think, I'm not sure there's actually a lp:mysql
[23:11] <spiv> gioele: well, lp:mysql-server is ~450M of history, although it's still in 1.9 format
[23:13] <Peng> gioele: You didn't make the destination repo 2a, did you?
[23:13] <gioele> Peng: everything is pack-0.92
[23:22] <gioele> Peng: couldn't I do that with 2a? I don't see why
[23:22]  * jelmer waves to igc, spiv, Peng and gioele
[23:23] <igc> hi jelmer!
[23:23] <gioele> lifeless: ping
[23:24] <lifeless> hi?
[23:24] <gioele> lifeless: may I ask you something (in a query) about the la_AU locale?
[23:25] <gioele> hi jelmer
[23:25] <jelmer> la_AU... is that what I think it is?
[23:25] <lifeless> jelmer: lingua latina
[23:25] <spiv> jelmer: hi :)
[23:25] <lifeless> the AU is a nonsense due to posix being naffed
[23:25] <lifeless> gioele: sure, or you can ask here.
[23:25] <gioele> oh, well, OK
[23:26] <Peng> gioele: It's just that trying to convert lp:mysql-server to 2a over the network ends in unhappiness.
[23:26] <lifeless> its not particularly private :>
[23:26] <gioele> I'm trying to create a locale as well (English language with European LC_*)
[23:26] <gioele> how did you test it?
[23:27] <lifeless> built packages, installed, ran shit.
[23:27] <lifeless> uhm, the xlib thing is the most tricky bit - gnome apps *ignore* xlib's locale support
[23:27] <gioele> did you sudo cp la_AU into /usr/lib/locales?
[23:27] <lifeless> so
[23:27] <lifeless> no
[23:28] <gioele> ok, I suppose I'll have to bzr-debuild some packages :)
[23:28] <lifeless> I patched gdm, libc6, libx11
[23:28] <gioele> lemme write that down
[23:28] <lifeless> these days you shouldn't need to patch gdm
[23:28] <gioele> these days? why?
[23:28] <lifeless> its been rewritten and no longer has a whitelist of locales.
[23:28] <gioele> ah, ok, one down
[23:29] <gioele> what should be done in libx11?
[23:29] <lifeless> there is a long list of keyboard processing stuff
[23:30] <lifeless> so you will need to pick a locale that works, find all references to it, and clone them to your new one.
[23:30] <lifeless> locales: why conflating data with different dimensions is a bad idea.
[23:32] <lifeless> breakfast time
[23:32] <lifeless> gioele: I blogged about this at the time, with links to my patches
[23:33] <lifeless> two separate blog posts I think, cause I realised libx11 was broken after the first patch.
[23:33] <gioele> lifeless: I read those, this is the reason I'm here asking these questions :)
[23:33] <gioele> the fact is I can't find a link to the libx11 issue
[23:33] <lifeless> hmm
[23:34] <spiv> poolie: no, I'm not on emacs-devel
[23:35] <lifeless> gioele: https://bugs.edge.launchpad.net/ubuntu/+source/libx11/+bug/423569 https://lists.ubuntu.com/archives/karmic-changes/2009-June/002209.html https://edge.launchpad.net/ubuntu/+archive/primary/+files/libx11_1.2.1-1ubuntu1.diff.gz
[23:35] <lifeless> poolie: you pung on a patch; I'll probably look at it in the new year.
[23:35] <poolie> k
[23:35] <poolie> is not urgent
[23:35] <poolie> just shows up in my activereviews page
[23:35] <lifeless> its bzr-email, right? get jam to review
[23:35] <lifeless> he has done a lot in that plugin as well
[23:36] <lifeless> or andrew :) - its a team branch I think, and I feel no special urge to control it
[23:38] <gioele> lifeless: thank you, the libx11 part does not look difficult at first sight (now that you dig into it ;))
[23:40] <johnjosephbachir> anyone here have much experience with split/join/ nested trees ?
[23:42] <xnox> Does a "$bzr checkout lp:project" have full branch history?
[23:42] <spiv> xnox: yes
[23:42] <xnox> But it is bound?
[23:42] <spiv> RIght.
[23:43] <spiv> If you run "bzr info", you'll see that the repository for it is local rather remote.
[23:43] <xnox> Ok. And I can run $bzr reconfigure to change from a regular branch to bound
[23:44] <xnox> Can a checkout still have :parent, :push and :submit?
[23:44] <xnox> Or bound to two places?
[23:46] <spiv> It can only be bound to one place.
[23:46] <spiv> Otherwise you'd have to deal with confusing situations like "bzr commit" successfully updating one place but failing on the other.
[23:47] <xnox> get it =) and confusing
[23:47] <spiv> Well, I guess in that case lock_write() each place first might be ok... but you get the idea :)  It's complex enough! :)
[23:48] <spiv> I believe a checkout "has" :parent etc, because actually those belong to the branch, so they are looked up on the bound branch if you have a checkout.
[23:49] <spiv> So they work, but I think they belong to the branch rather than checkout itself.
[23:49] <spiv> I'm not 100% certain about that.
[23:50] <xnox> I'll try to make a :parent :push and then reconfigure as bound
[23:52] <gioele> goodnight