[00:50] <cxo> How do you clone just the last revision of the repository?
[00:55] <mkanat> cxo: I think you might want bzr checkout --lightweight
[01:11] <spiv> lifeless: I suppose you saw the mail about setUpClass on python-dev?
[01:11] <mwhudson> spiv: that dull thumping sound is robert's head meeting the wall, i think
[01:11] <spiv> mwhudson: good good
[01:18] <lifeless> spiv: fuzzyman mailed  me directly
[01:18] <lifeless> spiv: I'm getting out of sprint backlog at the moment though
[01:31] <mwhudson> lifeless: the fix for https://bugs.edge.launchpad.net/bzr/+bug/513432 should be deployed now, do you have a simple recipe to verify?
[01:34] <james_w> mwhudson: create a local 2a repo, branch an older format in to it
[01:34] <mwhudson> james_w: ok, happens for every such attempt?
[01:35] <james_w> I think so
[01:35] <james_w> trying with the project I saw someone hit the problem with
[01:35] <mwhudson> it seems to be fixed then
[01:36] <james_w> yeah
[01:36] <lifeless> mwhudson: that should verify it, yes.
[01:36] <mwhudson> lifeless: ta
[01:36] <lifeless> mwhudson: and just to be sure, you did preserve the other hotfix we had ?
[01:37] <mwhudson> lifeless: the thread safety one?
[01:37] <mwhudson> lifeless: yes
[01:37] <mwhudson> (though the server in question _hasn't_ been rolled out to yet, so it still has a cowboy afaik)
[01:38] <lifeless> cool
[01:42] <poolie> mwhudson, thanks for that
[01:43] <mwhudson> poolie: np, it still seemed to take about a week longer than it should
[01:43] <RenatoSilva> lifeless: I have no idea of what "Show hits as a diff " means
[01:43] <poolie> i wasn't going t omention that :)
[01:43] <RenatoSilva> lifeless: and I can't get the problem with "Show revisions whose diff contains the search string"
[01:44] <RenatoSilva> lifeless: and mainly, how they relate to each other
[01:47] <lifeless> well, if you stay on irc for more than 60 seconds we can talk about it :)]
[01:47] <lifeless>  /rant
[02:33] <poolie> mwhudson, i added a bzrlib.initialize which you asked for
[02:33] <poolie> so you should give me a review :)
[03:03] <RAOF> Is there any way that bzr could preserve the rich-root status of a branch when branching from a non-rich-root branch into a rich-root repository?
[03:04] <RAOF> Now that 2a is the default repository, I tend to accidentally trap my changes into a rich-root situation and then pushing back to lp fails.
[03:25] <RAOF> Alternatively, how can I easily rescue a series of changes from a rich-root repository?
[03:27] <lifeless> RAOF: ideally get the other end to upgrade
[03:27] <lifeless> failing that for x in revno: bzr diff
[03:27] <RAOF> :(
[03:28] <lifeless> in principle rebase can do it
[03:28] <lifeless> there is a certain amount of '
[03:28] <lifeless> exercise for the reader
[03:28] <lifeless> '
[03:28] <lifeless> involved
[03:28] <RAOF> Would it be possible to somehow keep the non-rich-root status of a branch pulled into a rich-root repository?  This is a significant cause of friction I've run into.
[03:28] <lifeless> RAOF: not in the current repositories, not
[03:28] <lifeless> *no*
[03:29] <RAOF> But in future?
[03:29] <lifeless> its code, anything is possible.
[03:29] <lifeless> I don't expect anyone to do the heavy (and its fairly heavy I think) lifting involved
[03:29] <lifeless> we could make branch error unless given a flag
[03:29] <RAOF> Right.  That's what I wanted; an evaluation of whether it's worth filing a bug.
[03:29] <lifeless> though I'm not sure that that is a good idea
[03:30] <lifeless> RAOF: file a bug, we can gather 'affected by' counts ;P
[03:33] <RAOF> Looks like it's bug #506556
[03:34] <lifeless> me too it then :)
[03:35] <RAOF> Have done.
[08:11] <gerard_> morning
[08:23]  * vila waves@gerard_
[08:27] <vila> gerard_: I'm reviewing your patch
[08:27]  * emmajane waves.
[08:27] <vila> gerard_: out of curiosity, what editor are you using ?
[08:28] <emmajane> I've just had someone ask me about syncing upstream source with downstream plugins. Maybe like svn vendor branches? I know I've seen this asked about on the mailing list loads but I can't figure out where in the docs the answer is... it's not just tagging releases, is it?
[08:28] <vila> emmajane: weird, you were here during my late evening and you still here in my early morning, don't you ever sleep ??? :D
[08:28] <emmajane> vila, I'm in NZ. :)
[08:28] <emmajane> vila, It's 2130 here.
[08:28] <vila> emmajane: right, so we are both working far too late in the evening ;D
[08:29] <emmajane> :)
[08:30] <vila> upstream source and downstream plugins, the first is singular the second plural, are you talking about branches in both cases ?
[08:30] <emmajane> they're writing a plugin that needs to be synced with the upstream source.
[08:31] <mkanat> emmajane: That's a pretty standard DVCS case, it sounds like to me.
[08:31] <emmajane> yah.
[08:31] <vila> the upstream source is a plugin too or more than just the plugin ?
[08:31] <mkanat> emmajane: You just want to merge from upstream into downstream, right?
[08:31] <emmajane> mkanat, and know which version of the plugin applies to what upstream version of the full code base.
[08:31] <mkanat> emmajane: cd /local/checkout; bzr merge bzr://path/toupstream
[08:32] <mkanat> emmajane: Well, that's more a code decision than a VCS decision.
[08:32] <vila> emmajane: you don't strictly need to track the upstream version as long as you can merge
[08:32] <mkanat> emmajane: But if you do merge --remember, it remembers where you last merged from.
[08:32] <vila> it remembers at the first merge
[08:32] <emmajane> mkanat, so it would know that bug fix #3 applies to upstream release 4.0alpha?
[08:33] <mkanat> emmajane: What would know?
[08:33] <vila> --remember can be used to change afterwards
[08:33] <emmajane> it == the plugin that's being written.
[08:33] <mkanat> emmajane: If you check it in to that branch....
[08:33] <mkanat> emmajane: I assume you'd have different branches for the different upstream versions.
[08:34] <emmajane> ahh, right. so just a new branch for each version of upstream?
[08:34] <emmajane> yah
[08:34] <mkanat> emmajane: Yeah.
[08:34]  * emmajane nods
[08:34] <emmajane> http://wiki.bazaar.canonical.com/TrackingUpstream is that page what i'm looking for?
[08:34] <emmajane> I think I'm trying to make it harder than it is? :)
[08:34] <mkanat> emmajane: That's certainly possible. :-) It's very simple. :-)
[08:35] <mkanat> Anyhow, I'm off to bed. :-) Night all!
[08:35] <gerard_> vila: good :)
[08:35] <gerard_> vila: geany
[08:35] <gerard_> did it do weird stuff?
[08:36] <vila> gerard_: can you configure it to avoid leaving spaces at end of lines ?
[08:36] <gerard_> vila: yeah, no problem
[08:36] <vila> gerard_: not a big deal, but we try to get rid of these damn spaces :D
[08:37] <gerard_> invisible characters are annoying anyway
[08:38] <gerard_> a few days ago I had some trouble with a non breaking space char that was messing up search and replace :p
[09:13] <vila> gerard_: my gut feeling is that jam mentioned more cases than your tests covers, should I dig deeper or can you quickly confirm ?
[09:18]  * bialix waves heloo all
[09:18] <vila> hi bialix
[09:18] <bialix> bonjour vila!
[09:20] <bialix> hello davidstrauss, how's drupal dvcs contest going?
[09:21] <bialix> hi jelmer
[09:21] <gerard_> vila: yeah, he mentions one more
[09:21] <davidstrauss> bialix: Well enough. The debate for Drupal is turning out quite different from the one for most projects.
[09:22] <jelmer> HI bialix
[09:22] <gerard_> to be honest, I didn't check that one
[09:22] <gerard_> but I have a good feeling about it ;)
[09:22] <bialix> davidstrauss: that's good
[09:23] <vila> gerard_: good, I'm cleaning up some details and I let you know where to get an updated branch so you can build on it if that's fine with you
[09:23] <davidstrauss> bialix: I'm glad to see that it hasn't devolved into another silly performance contest. Just because performance gives easy objective numbers doesn't mean it's a good way to decide.
[09:23] <bialix> right
[09:24] <gerard_> vila: what do you mean with "build on it"?
[09:24] <vila> gerard_: more concretely, I'm looking into rewriting test_update_checkout_prevent_double_merge such as it's less verbose, you could then reuse the same tricks for further tests
[09:25] <gerard_> vila: ah ok, so you are cleaning it up and then showing me how it should have been in the first place? ;)
[09:25] <vila> gerard_: err, I meant test_update_remove_commit
[09:25] <bialix> it was funny (for me) to read comments about drupal contest in hg mailing list: there seems enough people who hate bzr for some reason so they're happy to see git in winners only because it's not bzr. crazy
[09:26] <vila> gerard_: hehe, not exactly, I prefer to view that as a gentle nudge in *improving* your tests :D
[09:26] <gerard_> vila: yeah, the test_update_remove_commit is really verbose :)
[09:26] <vila> gerard_: the way we write the tests is constantly evolving which means there are many bad examples in the existing ones and the good examples are hard to find
[09:27] <gerard_> I noticed
[09:28] <vila> test_update_remove_commit, especially because there is no conflicts, is a perfect candidate for using branchbuilder and can even become a whitebox test (which are far easier to debug than blackbox ones)
[09:28] <vila> and also faster
[09:30] <vila> hmm, good and bad are a bit rude, I meant old and new of course :D
[09:30] <vila> or rather new and old or bad and good whatever...
[09:32] <gerard_> blackbox tests are really easy to write though ;)
[09:34] <vila> gerard_: yup, you got what you paid for :D
[09:34] <gerard_> what I find interesting is that there are a lot of tests and still there are enough corner cases that are not tested
[09:57] <vila> gerard_: yeah, that just means there aren't enough tests yet, welcome to the debate, it's still open :D
[09:59] <vila> gerard_: one key argument is whether indirect tests (like blackbox ones) are enough to cover lower layers implementations (like your tests for wt._update_tree), that's precisely what I like to enhance with your submission :D
[10:00] <vila> gerard_: that's not strictly required to land your patch though, but if we can make the tests easier to write for that method...
[10:03] <gerard_> vila: easier sounds good :)
[10:47] <mvo> hm, what is the right command if bzr says my format is not compatible but bzr upgrade claims my branch format is the most recent one? http://paste.ubuntu.com/373111/ has the details
[10:49] <vila> mvo: actually, *you* use the most recent 2a format but the remote branch don't
[10:52] <mvo> vila: can I downgrade then? I do not want to upgrade the remote branch as I don't know who else is using it and with what bzr version(s)?
[10:56] <vila> mvo: you can't downgrade your branch, you had to re-create it from remote, they use different models :-/
[10:56] <vila> mvo: do you have a lot of commits there /
[10:56] <vila> mvo: do you have a lot of commits there ?
[10:57] <vila> mvo: and how did you end up there ?
[10:57] <mvo> vila: I ended up there via bzr co I think, let me check my shell history to be certain
[10:58] <vila> mvo: 'bzr info -v' will tell us about a shared repository too
[10:58] <mvo>     6  bzr co  lp:aptdaemon/0.2.x
[11:00] <vila> mvo: doing that locally gives me a 'Packs containing knits without subtree support' repo, not a 2a one
[11:00] <mvo> http://paste.ubuntu.com/373125/ <- that is the info -v output
[11:00] <mvo> bzr --version
[11:00] <mvo> Bazaar (bzr) 2.0.3
[11:01] <vila> mvo: did you 'bzr upgrade' when you wanted 'bzr update' ?
[11:02] <vila> mvo: try doing 'bzr co lp:aptdaemon/0.2.x' again and you should get a different 'bzr info -v' output
[11:02] <vila> mvo: 'bzr co' in a different place !
[11:04] <mvo> vila: right, sorry. the bzr co lp:aptdaemon/0.2.x one is the wrong line in my history, i was working with both branches and mixed them up. I don't have the trunk co in my shell history, so I guess the best workaround is to bzr co lp:aptdaemon/trunk again and just commit that. thanks for your help!
[11:05] <vila> mvo: you're welcome, feell free to come back or file a bug if you end up with such a setup
[11:05] <mvo> thanks, with the fresh checkout it works fine now
[11:05] <vila> mvo: that's not supposed to occur if you do't explicitly ask for it
[11:05] <vila> mvo: good
[11:05] <mvo> I guess I must have used bzr upgrade at some point that I just don't remember :(
[11:06] <mvo> maybe it could warn for co branches if the local and remote one become incompatible when bzr upgrade is issued?
[11:09] <vila> mvo: sounds like a good idea, care to file a bug ?
[11:10] <mvo> vila: thanks, I will do that (after lunch :)
[13:13] <gerard_> vila: did you get around to beautifying the test yet?
[13:14] <vila> gerard_: almost :D Got distracted and also ran into unsuspected complications, but the final result should be something like: http://paste.ubuntu.com/373202/
[13:18] <gerard_> vila: hmm, it sure is more compact, but hard to read when you're not used to it
[13:18] <vila> gerard_: which part ?
[13:22] <vila> gerard_: i.e. where should I add comments to make it clearer ?
[13:23] <gerard_> vila: if you haven't seen build_snapshot being used before, you have a hard time making sense of it
[13:24] <vila> gerard_: ha, yes, you need to look at branchbuilder a bit, but that far easier to build graphs than with run_bzr
[13:25] <vila> gerard_: but now we have the workingtree object and we can make far more assertions with it and more precise ones too
[13:37] <vila> gerard_: http://paste.ubuntu.com/373215/
[13:38] <vila> gerard_: http://paste.ubuntu.com/373216/ without the typo :D
[13:40] <vila> gerard_: does it make sense ? Do you think you can write other tests from that ?
[13:41] <gerard_> not quickly unless you provide some documentation for build_snapshot
[13:42] <gerard_> and I was not really planning to write more tests...
[13:43] <gerard_> that is, until I'm fixing a new bug or building a new feature
[13:43] <vila> ha, I thought you were rejoicing  about TDD yesterday, I misinterpreted that a will to write more tests :D
[13:43] <vila> gerard_: no problem, I'll write them
[13:44] <gerard_> hehe, I like it when working on something, I don't like testing in itself
[13:45] <vila> hehe, yeah, the usual "I love existing tests but... why should I add more ?" :-P
[13:48] <gerard_> vila: well, I like adding tests for existing bugs
[13:49] <gerard_> just writing tests out of the blue seems like a waste of time
[13:49] <gerard_> I feel that's the responsibility of the guy that wrote the feature in the first place
[13:49] <vila> gerard_: yeah, I agree with that, but what do you do when tests are missing then ?
[13:50] <gerard_> vila: so how do you know they are missing?
[13:50] <vila> gerard_: because I can't find them :D But I don't have any problem if you don't add them, they were missing before your patch, don't get me wrong !
[13:51] <gerard_> vila: no, seriously, how do you know what test you can't find?
[13:52] <vila> gerard_: there is no general rule, but here, I couldn't find tests for wt._update_tree() nor wt.update() only blackbox ones...
[13:53] <jelmer> vila: what's the name of the 2.1 branch? I tried to submit that cherrypick during lunch but lp kept timing out :-/
[13:53] <gerard_> vila: that's the reason they were so broken then
[13:53] <vila> gerard_: which ones ?
[13:53] <gerard_> _update_tree() mostly
[13:53] <vila> jelmer: lp:bzr/2.1 ?
[13:54] <gerard_> that -r feature was seriously not working correctly, can tell that from the code
[13:54] <vila> oh, you mean the code, I thought you were referring to the tests
[13:54] <jelmer> vila: argh, way too obvious - thanks
[13:54] <gerard_> vila: no, the tests were fine
[13:54] <vila> gerard_: you mean you identified other bugs ?
[13:54] <jelmer> vila: (I tried ~bzr/bzr/2.1 and that failed)
[13:54] <vila> jelmer: that's why you couldn't find it ;D
[13:54] <gerard_> vila: yeah, using -r to go to somewhere before you branched cannot have worked correctly
[13:54] <vila> jelmer: pfft, so last century....
[13:55] <jelmer> vila: Well, being able to look at http://code.launchpad.net/bzr would help too :-)
[13:55] <vila> jelmer: lp ooopsing again ? I can read that page without problems
[13:56] <jelmer> vila: I reproducibly get a timeout
[13:56] <vila> gerard_: you scare me there, and reinforce my feeling that your patch do more than its tests :-/
[13:56] <vila> jelmer: I can't reproduce that
[13:57] <gerard_> vila: it was using graph.find_unique_lca(revision, old_tip) to find the branch point
[13:57] <gerard_> but if revision is before the branch, that will just return revision
[13:58] <gerard_> the whole update was horribly broken (I repeat myself here)
[13:59] <gerard_> but I agree it probably needs more tests
[13:59] <vila> what do you mean 'revision is before the branch' ?
[14:00] <gerard_> if you branched at revision 2, and do update -r 1
[14:00] <vila> gerard_: oh, and by more tests I don't mean you introduced more bugs, but adding tests when you diagnose a bug guarantees that we won't regress
[14:01] <gerard_> vila: we should probably add a test that update -r will properly remove revisions
[14:01] <gerard_> just like the test that checks if it removes the commit from the branch
[14:04] <jelmer> vila: does http://code.lp.net/launchpad work for you ?
[14:06] <vila> redirected to http://www.ndparking.com/lp.net
[14:07] <vila> https://code.edge.launchpad.net/launchpad works fine
[14:08] <vila> jelmer: and http redirects to https
[15:50] <vila> jam: can I land https://code.edge.launchpad.net/~jelmer/bzr/2.1-fix-foreignrev/+merge/19008 into 2.1 ?
[15:51] <jelmer> vila: please do
[15:51] <gerard_> vila: :)
[15:52] <vila> gerard_: congratulations, your patch is landing :D
[15:52] <vila> jelmer: hello acting RM :D
[15:55] <jam> vila: sure
[15:57] <bialix> does configuration of ML has changed recently/
[15:57] <bialix> ?
[15:57]  * bialix feels blacklisyted
[15:58] <gerard_> vila: thx
[15:59] <vila> bialix: not that I know of. Why the feeling ?
[15:59] <vila> jelmer: pqm'ed
[15:59] <bialix> I can't post via gmane, 3 mails sent today, none appears
[16:00] <bialix> (maybe I've reached my limit of ... something)
[16:01] <vila> bialix: weird
[16:02] <bialix> posting to other ML via gmane was success
[16:02] <jelmer> vila, thanks!
[16:02] <bialix> indeed, weird
[16:04] <bialix> abentley: unshelve with editor works very nice, thanks!
[16:04] <abentley> bialix, you're welcome.
[16:05] <bialix> :-)
[16:07] <bialix> abentley: one minor UI thing: if I've invoked editor to work with several changes in one file then it invoked only once, that's ok; but final confirmation slightly misleading: "Shelve 2 changes?" -- and I think: "strange, I've edited the file only once".
[16:07] <abentley> bialix, I believe that means "two lines changed".
[16:08] <bialix> it's not very obvious
[16:08] <bialix> usually it the count of hunks
[16:08] <bialix> abentley: maybe "Shelve selected changes" would be more neutral
[16:09] <abentley> bialix, that could make sense.
[16:10] <bialix> abentley: also, if I've invoked "shelve --destroy" it will be nice to see more strong confirmation question: "Destroy selected changes?". but all this UI things, maybe I'm wrong
[16:11] <abentley> bialix, yes, there's always tension between providing a consistent UI and a specific UI.
[16:11] <bialix> perhaps I need dump this questions as bug report?
[16:11] <abentley> bialix, sure.  They're good questions, and I'm not sure what the right answers are.
[16:12] <bialix> ok
[16:12] <maxb> abentley: Hello. For bzrtools, do you like people to use the "Resubmit" button on MPs accepting that it disturbs the comment train, or to just comment and ping you to request re-review?   (https://code.edge.launchpad.net/~maxb/bzrtools/skip-import-.bzr in my case)
[16:12] <abentley> maxb, the latter.
[16:12] <maxb> do you consider yourself pung, or would you like an email? :-)
[16:16] <abentley> maxb, let's say I'm pung.
[16:17] <bialix> abentley: done: https://bugs.launchpad.net/bzr/+bug/519919
[16:21] <gerard_> vila: I guess the fix will not get into 2.1?
[16:21] <gerard_> or will it?
[16:22] <vila> gerard_: I don't think so, 2.1.0final is around the corner
[16:49] <Noldorin> hi
[16:50] <Noldorin> how can i ignore all files under a certain folder in .bzrignore?
[16:54] <jelmer> Noldorin: Add 'foldername/*' to .bzrignore
[16:55] <Noldorin> jelmer, yeah, that doesn't work for some reason
[16:56] <jelmer> Noldorin: is the directory itself versioned?
[16:56] <Noldorin> yeah
[16:56] <Noldorin> if i have just '*.xap' it works
[16:56] <Noldorin> but if i have 'ClientBin/*.xap', no luck
[17:02] <Noldorin> jelmer, ?>
[17:05] <gerard_> Noldorin: how about just "ClientBin"?
[17:06] <Noldorin> gerard_, i need to actually include the folder in the repo, strangely enough, but none of the contents
[17:07]  * gerard_ wonders what the use of having an empty directory underversion control is
[17:07] <Noldorin> gerard_, it's a quirk of Visual Studio. it needs the folder to be there
[17:08] <gerard_> Noldorin: create it in a pre-build action?
[17:08] <Noldorin> gerard_, yeah, that just crossed my mind heh.
[17:08] <jelmer> Noldorin: no idea, sorry
[17:08] <Noldorin> no prob
[17:09] <Noldorin> got it sorted now. thanks guys
[17:09] <Noldorin> jelmer, oh btw. do you remember some time ago when we were looking into hacking the bzr-git/dulwich source to investigate the problem with pushing to git-hub?
[17:10] <Noldorin> i was getting somewhere actually
[17:10] <Noldorin> wondered if you had a few mins to continue with that
[17:10] <jelmer> Noldorin, sure
[17:10] <Noldorin> jelmer, i can't remember exactly where we were, but i remember confirming the path was correct
[17:14]  * bialix waves at GaryvdM
[17:14] <bialix> vila, jam: is it possible that posts from gmane blacklisted?
[17:15] <jam> bialix: I suppose it is possible, but I wouldn't think so
[17:16] <Noldorin> jelmer, is it worth upgrading from 0.4.2 to 0.4.3 for a start?
[17:16] <bialix> it seems my usual mail marked as spammer or something similar (given the answer about waiting approval I've got recently)
[17:17] <bialix> jam: http://pastebin.com/d7df6fa4b
[17:17] <bialix> jam: who can help me in such situation?
[17:18] <bialix> it seems some software on mailman server was upgraded today?
[17:19] <GaryvdM> Hi bialix
[17:19] <GaryvdM> Hi all
[17:20] <bialix> Hi Gary
[17:20] <vila> hey GaryvdM !
[17:20]  * bialix feels really blacklisted and with tag "spammer" on the back goes away in sadness: goodbye cruel world!
[17:24] <vila> bialix: could it be that your From header has changed ?
[17:24] <bialix> vila: I'm even don't understand what you're say right now.
[17:25] <bialix> I think I have not changed anything
[17:26] <bialix> my "From:" seems the same as yesterday, just my name and surname
[17:26] <vila> mails have headers and a body, the headers are (roughly) lines of the form '<header_name>: value'
[17:26] <bialix> yes, yes, vila it was silly joke
[17:27] <vila> ha :D
[17:27] <bialix> but I really have no idea how to screw this in Thunderbird
[17:27] <chx> hi. in the "which VCS to pick" http://groups.drupal.org/node/48818?page=1#comment-131203 we have a user who tried bzr on mac with not much success. can someone people help me with a nice reply?
[17:27] <bialix> chx: install bzr from installer is good answer?
[17:28] <bialix> there is only small issue with Qt
[17:28] <chx> bialix: i do not have OS X.
[17:28] <bialix> another silly joke
[17:28] <bialix> heh, I really need head to home
[17:28] <vila> chx: there is an OSX package for bzr, I don't know who is maintaining the macports one
[17:28]  * bialix waves bye all
[17:28] <chx> vila: Next try was installing the binaries for OS/X 10.6 from Canonical's website after cleaning out the Macports install.
[17:28] <chx> vila: it seems he tried.
[17:30] <vila> what's doxxx nick here ?
[17:31] <vila> BasicOSX: do you use the mac installer ?
[17:32] <GaryvdM> chx: Difficult to tell what went wrong with the installer.
[17:32] <vila> verterok: do you use the mac installer ?
[17:32] <GaryvdM> chx: Critical point: "Trying "bzr explore" from the command line in a bzr-repository failed miserably with ever more error messages piling up on my screen."
[17:32] <vila> GaryvdM:
[17:33] <GaryvdM> I installed bzr on a client
[17:33] <GaryvdM> I installed bzr on a client's mac the other day with no major issues.
[17:34] <GaryvdM> using the installer
[17:34] <vila> GaryvdM: and using bzr-explorer ?
[17:34] <RenatoSilva> verterok: hi
[17:34] <verterok> vila: hi, it's been a while since I booted into OS X :/
[17:34] <verterok> RenatoSilva: hi
[17:35] <verterok> vila: so, the answer is: not recently :)
[17:35] <RenatoSilva> verterok: did you remember if you have already added an encoding param in bzr-xmloutput?
[17:35] <jam> bigjools: I just sent it through
[17:35] <chx> GaryvdM: i do not have more info than this
[17:35] <RenatoSilva> verterok: because I remember something like this...
[17:35] <verterok> RenatoSilva: I didn't
[17:35] <jam> sorry, meant to say 'bialix'
[17:35] <bigjools> easy mistake :)
[17:35] <chx> GaryvdM: but someone chiming in from the bzr community would be nice to counter this bad experience (which obviously should not affect the choice but it will)
[17:35] <jelmer> Noldorin, yeah, upgrading is definitely useful
[17:35] <RenatoSilva> verterok: there's already branch for that?
[17:36] <jelmer> Noldorin, actually, I was assuming you were using trunk...
[17:36] <GaryvdM> vila: Yes, Bzr explorer, There is no shortcut created, but I could run it fine from the command line
[17:36] <verterok> RenatoSilva: No, there is a branch with a --encoding option for the xmlrpc-service, but that's not what we talked yesterday ;)
[17:37] <RenatoSilva> verterok: oh so it's the xml rpc, ok
[17:37] <GaryvdM> chx: He maybe did not install the qt binaries, which has to be done manualy
[17:37] <chx> GaryvdM: maybe the installer should warn ?
[17:38] <GaryvdM> chx: yes.
[17:38] <GaryvdM> I'll reply.
[17:39] <vila> hmm, the coyote is efficient...
[17:40] <chx> GaryvdM: thanks!
[17:43] <Noldorin> jelmer, heh, ok. will do so now
[17:44] <Noldorin> jelmer, getting a horrible error now :S
[17:45] <Noldorin> jelmer, never mind, that disappeared
[17:45] <Noldorin> jelmer, anyway, all upgraded now. how to proceed?
[17:48] <jelmer> Noldorin: are you running bzr-git trunk?
[17:51] <Noldorin> jelmer, 0.43 now
[17:52] <SamB_XP> what, he does releases of tht?
[17:54] <Noldorin> jelmer, upgrade to trunk?
[17:55] <jelmer> Noldorin, please do
[17:55] <Noldorin> jelmer, ok, done now :)
[17:56] <Noldorin> jelmer, same error, of course
[17:56] <Noldorin> but anyway...
[17:57] <Noldorin> which file should we start off messing with?
[17:58] <jelmer> Noldorin, I'm adding some debug code
[17:58] <Noldorin> jelmer, ah, great
[18:01] <jelmer> Noldorin, done
[18:01] <jelmer> please pull again
[18:01] <jelmer> please try again and use -Dtransport
[18:01] <jelmer> this'll write extra info to ~/.bzr.log
[18:02] <Noldorin> ok
[18:03] <jelmer> I'll be back in ~30 minutes
[18:05] <Noldorin> jelmer, ok
[18:07] <BasicOSX> vila:  no, I run bzr.dev
[18:07] <BasicOSX> (sorry for the late response)
[18:07] <vila> BasicOSX: better late than never :D And you use bzr-explorer or not ?
[18:08] <BasicOSX> not ... my roots are unix and most of my work is done on linux
[18:08] <BasicOSX> CLI server stuff
[18:09] <BasicOSX> Just taking poll? or looking for more feedback?
[18:09] <vila> BasicOSX: trying to update my mental Who's Who :D
[18:10] <BasicOSX> Then you'll need some mental floss after talking to me :-P
[18:11] <vila> jam: wt.list_files() raising OSError when trying to lstat  a non-normalized Unicode filename... rings a bell ?
[18:12] <vila> BasicOSX: Ok, I stop right now then :D
[18:14] <GaryvdM> Bla, me too
[18:15] <GaryvdM> groups.drupal.org says "Your submission has triggered the spam filter and will not be accepted."
[18:15] <fullermd> Who's who?  Me's me.
[18:16] <Noldorin> jelmer, doesn't print anything in dtransport now :S
[18:28] <jelmer> Noldorin, re
[18:28] <jelmer> Noldorin, did you try adding -Dtransport on the commandline ?
[18:28] <jelmer> Noldorin, and nothing shows up in .bzr.log ?
[18:28] <vila> jam: for WorkingTreeFormat2 that is
[18:33] <GaryvdM> Hmm. For bzr 2.1, I thought that python-testtools was only a requirement if you are going to run the test suit.
[18:34] <GaryvdM> Some commands (like update) fail if you don't have it.
[18:34] <GaryvdM> Was this intended?
[18:36] <GaryvdM> vila ^
[18:39] <vila> GaryvdM: If sftp is involved you're running into bug #516183
[18:39] <vila> GaryvdM: the fix should be included in 2.1.0final but is still present in 2.1.0rc2
[18:41] <fullermd> Heh.  It's funny how two wrongs make a right.
[18:41] <jelmer> Noldorin, ?
[18:41] <fullermd> I never had a chance to run into that bug, since I yanked paramiko off my systems after the pycrypto upgrade left it bleating all the time   :p
[18:42] <GaryvdM> vila: Ok I was using sftp. So I'm not going to add testtools as a dependency to the debs in the ppa.
[18:43] <vila> jam: I'm banging my head on the failing tests for https://code.edge.launchpad.net/~vila/bzr/322767-dont-add-conflict-related-files/+merge/18858, if you could have a look during my night, I'm sure I will sleep better ;) I can't figure why using wt.list_files() *during* smart_add fails while using it after succeeds (or something like that)
[18:44] <vila> GaryvdM: testtools should be a Build Dep for bzr
[18:44] <jam> vila: ... WT.list_files() often fails because we get the offending file back in plain str form, and stuff like 'list.sort()' raises a UnicodeDecodeError trying to compare that string to others.
[18:44] <jam> but sure, I'll look at your work
[18:44] <vila> GaryvdM: i.e. something you need to build (ok, test) but not when *using* it
[18:44] <GaryvdM> vila: Ah yes.
[18:46] <vila> jam: here we fail in a call to file_kind() which calls os.lstat AFAICT with the normalized form when the not normalized form has been used on disk
[18:46] <jam> vila: well, I'm not going to try to solve Mac issues :)
[18:46] <jam> at least, not yet
[18:46] <vila> not on mac ! It's on karmix/etx3
[18:46] <vila> yeah karmic even
[18:47] <jam> hmm.... maybe we failed to remove some of the normalization code
[18:48] <vila> anyway, the mp gives a subset that includes the failing tests (they succeed without my patch ...)
[18:48]  * vila is off
[18:53] <GaryvdM> Is there something similar to a bzr checkout (aka bound branch) in git?
[18:56] <jam> GaryvdM: past experience seems to indicate no, but I haven't checked again recently
[18:57] <GaryvdM> jam: Ok, I'm going to state that in a forum.
[18:58] <jam> I believe they have 'stacking', but only for local (I don't believe you can stack across a network boundary)
[18:58] <jam> there are also some strange things you can do with env vars
[18:59] <jam> vila: in case you are still here, what is failing is that calling 'conflicts' to list what files are conflicted has to walk the whole filesystem because it has to search for .BASE, etc files.
[18:59] <jam> You change causes us to invoke '.conflicts' in a case where we didn't before
[19:00] <jam> So I think it was already broken, we just didn't know it, because we weren't calling it in those circumstances
[19:00] <jam> I would consider adding a KnownFailure for WTF2 in that case
[19:00] <jam> not worth the effort to fix, IMO
[19:02] <jam> well, I should say, fixing list_files() is worthwhile at some point, but not worth blocking your patch for
[19:33] <Noldorin> jelmer, sorry, thought you had left.
[19:33] <Noldorin> jelmer, well, let me paste you the output
[19:36] <Noldorin> http://pastebin.com/m62241839
[19:36] <Noldorin> jelmer, that's all i get
[19:38] <jelmer> re
[19:38] <jelmer> Noldorin, did you pull from trunk after I added that debug output?"
[19:42] <Noldorin> jelmer, yep
[19:44] <Noldorin> jelmer, just double check - it is up to date. what were you expecting?
[19:50] <vila> jam: passing rapidly post-lunch, ha, that makes sense and kind-of imply that Unicode is badly supported for WorkingTreeFormat2. So accepting my patch means we won't support adding files for that format, but given the big red flashing warning to upgrade from that format, I think that's acceptable.
[19:51] <jelmer> Noldorin, what revno of bzr-git do you have?
[19:51] <vila> jam: can I consider adding the expected failures  as a BB:tweak ?
[19:51] <Noldorin> jelmer, r708
[19:52] <jelmer> Noldorin, are you sure that's the version actually being loaded? using -Dtransport I get more debug output in ~/.bzr.log..
[19:53] <Noldorin> judging by the log, it is
[19:53] <Noldorin> one sec
[19:53] <jam> vila: yes
[19:54] <vila> jam: thanks, I'll sleep better :D
[19:54] <dahoste> hey #bzr.
[19:55] <Noldorin> jelmer, how can i check?
[19:55] <jelmer> Noldorin, "bzr plugins -v"
[19:57] <GaryvdM> jelmer: I want to update bzr-svn, and bzr-rebase and add bzr-git to the beta ppa. I'm not sure which is the best way to go about this.
[19:57] <GaryvdM> jelmer: E.g. One of the questions I have is for bzr-svn, should I start with lp:~bzr/bzr-svn/<ubuntu- ver>-ppa or lp:~debian-bzr-svn/bzr-svn/unstable
[19:58] <dahoste> Question: I'm trying to get some shared-repo branches exposed via wsgi+apache.  Works fine for a non-shared repo branch, but fails for a shared repo.  I get: " An attempt to access a url outside the server jail was made".   Something to do with how the transport is created.. but not sure how to tweak it to make it work.
[19:59] <dahoste> My little wsgi handler is using the make_app() function from bzrlib.transport.http.wsgi.
[19:59] <Noldorin> jelmer, erm, how do i rebuild?
[19:59] <Noldorin> i think i need to do that now
[20:00] <Peng> dahoste: Upgrade to bzr 2.1.0rc1.
[20:00] <jelmer> GaryvdM: the debian packages are on http://bzr.debian.org/pkg-bazaar/bzr-X/unstable
[20:00] <Noldorin> oh, never mind
[20:00] <Noldorin> need to add back in the hack
[20:00] <Noldorin> one sec
[20:01] <jelmer> Noldorin: there's nothing to rebuild, it's just python files
[20:01] <jelmer> GaryvdM: the packages on launchpad are outdated (mirrors/imports don't work for packaging branches yet)
[20:01] <GaryvdM> jelmer: Should I base the ppa packages on http://bzr.debian.org/pkg-bazaar/bzr-X/unstable?
[20:02] <dahoste> Peng, .... ok.  Was this a known issue, then, that is definitely fixed?  I'm not averse to implementing a more substantial wsgi handler, if that's all it takes.
[20:02] <jelmer> GaryvdM: Yeah
[20:02] <Noldorin> ok, seems i've got to update dulwich too...
[20:02] <GaryvdM> jelmer: cool
[20:02] <jelmer> Noldorin: you shouldn't have to, bzr-git trunk and bzr-git 0.4.3 require the same dulwich
[20:03] <Noldorin> jelmer, i haven't updated since 0.4.2
[20:03] <Noldorin> so yes i think i need to
[20:03] <jelmer> Noldorin, but then cloning wouldn't have worked earlier either
[20:03] <Noldorin> ok, working now
[20:03] <Noldorin> hmm
[20:03] <Peng> dahoste: Yes, it's been fixed. Bug #348308.
[20:04] <Peng> dahoste: If you don't want to upgrade bzr, you can put a simple monkeypatch in your WSGI script, but upgrading would be better...
[20:04] <Noldorin> jelmer, http://pastebin.com/m5950138d
[20:05] <Noldorin> seems to be including your debug info now :)
[20:07] <Peng> dahoste: My favorite version of the monkeypatch is http://paste.pocoo.org/show/176320/, FYI.
[20:07] <dahoste> Peng, hmm... I apologize for not seeing that.  I did search the bugs.   Weird - searching on either 'wsgi' or 'jail' doesn't bring up 348308.
[20:07] <Noldorin> jelmer, i guess the problem is where the ssh key is transported over the git connection?
[20:08] <Peng> dahoste: Don't sweat it, I never find anything searching Launchpad either. I think it excludes fixed bugs by default?
[20:09] <dahoste> Peng, cool, that should be enough to get me going.  I'm not averse to upgrading, but I'm using gentoo and avoid stepping outside of portage unless it's a security issue or something.  They've still got 2.1.0-beta4 masked.  I'll monkeypatch in the interim.
[20:11] <Peng> dahoste: OK. :)
[20:12] <dahoste> Peng, thanks for the quick info.   irc ftw, as usual.
[20:12] <Peng> dahoste: I used to have that bug number memorized, though I've started to forget it since it was fixed, since I run bzr.dev. :P
[20:13] <Noldorin> jelmer, any ideas?
[20:14] <dahoste> Peng, I'll admit I was surprised that this didn't 'just work'... figured everyone was running their repos through wsgi, and it would be well-paved for all the common scenarios.
[20:14] <jelmer> Noldorin: as far as I can tell the ssh bit works ok
[20:14] <GaryvdM> Interesting: http://upsilon.cc/~zack/stuff/img/vcstype-year.png (Graph of Debian VCS usage)
[20:15] <Peng> dahoste: For some reason, very few people use the WSGI server.
[20:15] <Peng> dahoste: If they want good performance, they just use bzr+ssh.
[20:18] <dahoste> Peng, I almost went that route.. but wanted to avoid dealing with full shell accounts.  Though I think there's a way to use a single account, not sure.  Anyway, with wsgi, I can just defer to apache to auth through ldap for write access.   I'm prepping to migrate a ton of svn repos over to bzr, and wanted to maintain as much of the auth environment as possible.
[20:19] <Peng> dahoste: Ooh, you're going to do HTTP writing too? That's probably even less common.
[20:19] <dahoste> Peng, yup.   fingers crossed.  :)
[20:21] <Noldorin> jelmer, hmm ok. so what now then?
[20:22] <GaryvdM> jelmer: When I'm done, should I push --overwrite to lp:~bzr/bzr-svn/<ubuntu-ver>-ppa?
[20:22] <jelmer> can you try adding self._path = self._path.strip("/") after the call to trace ?
[20:23] <jelmer> GaryvdM, please do
[20:23] <GaryvdM> Ok
[20:24] <Noldorin> jelmer, strangest thing is that ssh auth works perfectly for bzr/launchpad....
[20:25] <GaryvdM> ah lp:~bzr/bzr-svn/<ubuntu-ver>-ppa has allready been merged with  http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/ -- Cool
[20:32] <jelmer> Noldorin, any luck?
[20:33] <Noldorin> jelmer, see my previous message
[20:33] <jelmer> Noldorin, <jelmer> can you try adding self._path = self._path.strip("/") after the call to trace ?
[20:46] <jelmer> Noldorin: any luck?
[21:03] <jelmer> Noldorin, still there?
[21:41] <Noldorin> jelmer, seems we keep missing each other.
[21:41] <Noldorin> jelmer, oh, i thought that comment was to someone else, sorry.
[21:41] <jelmer> Noldorin: can you pull from current trunk
[21:41] <Noldorin> jelmer, what file/position?
[21:41] <jelmer> Noldorin, and try again
[21:41] <Noldorin> ok
[21:42] <Noldorin> coo
[21:44] <Noldorin> jelmer,
[21:44] <Noldorin> http://pastebin.com/m1a840bb5
[21:44] <Noldorin> that's running dpush -Dtransport on the latest revision
[21:46] <Noldorin> jelmer, doesn't look any different
[21:49] <Noldorin> hmm
[21:57]  * Noldorin pings jelmer 
[21:58] <jelmer> Noldorin, sorry, I'm out of ideas
[21:59] <Noldorin> hmm
[22:00] <Noldorin> jelmer, what did you expect to see in that trace?
[22:10] <poolie> good morning
[22:10] <GaryvdM> Hi poolie
[22:10] <Noldorin> jelmer, (if you were looking for anything at all)
[22:11] <poolie> hello gary
[22:12] <Peng> mwhudson: BTW, looks like my mirrored branches are happy again...
[22:12] <mwhudson> Peng: oh good
[22:13] <Peng> I guess the gremlins have been placated?
[22:18] <GaryvdM> There were lots of critical bugs in 2.1.0rc2 (that have been fixed). I think we should maybe do a rc2
[22:19] <GaryvdM> *I think we should maybe do a rc3
[22:19] <GaryvdM> Bug #515597 makes rc2 unusable
[22:21]  * mtaylor made bzr  crash...
[22:22] <mtaylor> bzr revision-info lp:~mordred/+junk/testme
[22:22] <mtaylor> gives:
[22:22] <mtaylor> bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction on LockableFiles(lock, file:///home/mordred/src/testme/.bzr/branch/)
[22:24] <mwhudson> revision-info is pretty weird about its arguments
[22:25] <mwhudson> mtaylor: i think what that command tries to do is number the tip of lp:~mordred/+junk/testme in the branch in your cwd
[22:25] <mtaylor> mwhudson: lovely
[22:25] <mwhudson> or something like that
[22:25] <mwhudson> yeah
[22:25] <mtaylor> mwhudson: is there a command I'm missing then that would give me the revision-id of the tip of the branch specified?
[22:26] <mwhudson> mtaylor: bzr revision-info -d lp:~mordred/+junk/testme
[22:26] <mwhudson> (i added the -d option in an extreme rage a while ago)
[22:26] <mtaylor> mwhudson: what does -d do?
[22:26] <mtaylor> awesome. rage is a good source of commands
[22:26] <mwhudson> mtaylor:
[22:26] <mwhudson>   -d ARG, --directory=ARG
[22:26] <mwhudson>                         Branch to examine, rather than the one containing the
[22:26] <mwhudson>                         working directory.
[22:26] <mtaylor> ah. heh
[22:27] <GaryvdM> jelmer: I've gotten (and upgraded) lp:~bzr/bzr-svn/karmic-ppa/ and run merge http://bzr.debian.org/pkg-bazaar/bzr-svn/unstable/
[22:28] <GaryvdM> jelmer: I'm not sure how to handel the merging of changelog
[22:28] <GaryvdM> There are some entries from debian/unstable that have been added
[22:29] <GaryvdM> jelmer: Do I keep these?
[22:33] <GaryvdM> jelmer: I think that I'm going to revert merges changes to debian/changelog, and create my entry (with version number for the ppa)
[22:59] <spiv> Good morning.
[23:44] <GaryvdM> How do I get bzr builddeb to not download the .orig.tar.gz with uscan, but to rather use the code from the branch?
[23:45] <james_w> GaryvdM: you need to use "merge-upstream" to merge the code from the branch, and pass the tarball if there is one corresponding to the release you are using
[23:46]  * GaryvdM is confused
[23:47] <GaryvdM> ah merge-upstream is a builddeb command
[23:51] <AfC> Given an arbitrary Debian package in Ubuntu, what's the bzr command to get a Bazaar branch of its sources? [is there one?]
[23:53] <james_w> bzr branch lp:ubuntu/<package>
[23:55] <GaryvdM> james_w: I cant get merge-upstream to work, but I think I have don what it does manually, so I'm not to worried.
[23:56] <igc> hi
[23:57] <igc> hi poolie, jam, garyvdm, james_w
[23:58] <GaryvdM> james_w: My org question is theoretical, because the .orig.tar.gz should be the same as the contents of the branch, but what if I have modified the code in the branch so that it differs from the .orig.tar.gz?
[23:58] <GaryvdM> Hi igc!
[23:59] <james_w> hi igc
[23:59] <james_w> GaryvdM: the way that .deb repositories work mean that you have to have a byte-for-byte identical .orig.tar.gz for versions that share the same upstream version