[00:38] <arcfide> Hey, is there anyone here who can point me in the right direction on BZR?
[00:38] <arcfide> Basically, I was tracking some code through BZR, but I have not done so in some time.
[00:39] <arcfide> It appears that they have changed names and the like on me, and I also have a number of changes of my own that I want to track and possibly send upstream.
[00:39] <arcfide> What is the way to change branches inside of a workspace?
[00:43] <bignose> arcfide: each branch has its own working tree.
[00:44] <arcfide> bignose: Um, so, what does that mean?
[00:44] <bignose> arcfide: if you want a different branch, use ‘bzr branch’ which will create that branch's working tree.
[00:44] <bignose> arcfide: multiple branches without switching directories is not the normal Bazaar mode of working.
[00:44] <arcfide> How do I get my changes from this current tree into that one?
[00:45] <bignose> arcfide: they're distinct branches, right? you want the branches to continue to have their own line of history?
[00:46] <arcfide> bignose: Well, no, so, the project I was tracking changes their name and the branches and URLs and the like, I just want to figure out how to get all of my changes in line with their changes while still playing nice with my own version history, which I actually keep in Monotone.
[00:46] <arcfide> I do my development in Monotone, but then I want to package something up so that I can send my changes upstream uzing Bazaar, which is what they use.
[00:46] <bignose> arcfide: it sounds like you want to merge from their branch into yours.
[00:46] <arcfide> Thus far I have committed no changes to the tree using Bazaar.
[00:47] <arcfide> Well, I don't want to have my own branch.
[00:47] <bignose> arcfide: that will bring the revision data in, merge (possibly leaving you to fix conflicts), then leave the working tree in a state for you to test
[00:47] <bignose> once you're happy the merge is as you want it, you commit that and continue.
[00:48] <bignose> arcfide: “playing nice with my own version history seems to necessitate you having your own branch.
[00:48] <arcfide> Well, so, I want to take my changes and merge them into their branch, not the other way around.
[00:48] <bignose> arcfide: you can't merge into someone else's branch; they do that.
[00:48] <arcfide> bignose: Sorry, my own version history is kept outside of Bazaar in Monotone (another VCS), I only want to put into the Bazaar history those things that I need to send upstream.
[00:49] <bignose> you don't have write permission to their branch, right?
[00:49] <arcfide> I will probably be getting it.
[00:49] <arcfide> Maybe I don't know how to word it correctly, I'm basically a BZR newb.
[00:49] <bignose> arcfide: so how are you going to get the Monotone VCS data into Bazaar?
[00:50] <arcfide> I'm not.
[00:50] <arcfide> I'm going to roll up single patches to push up, but I don't want the history to move over.
[00:50] <arcfide> So LIke this:
[00:50] <arcfide> 1. Grab their source; 2. Make lot's of little changes tracked in Monotone; 3. When things are ready, make a patch/commit into the Bazaar system and push upstream.
[00:51] <bignose> arcfide: between the latter two steps is an implied “get my Monotone VCS data into Bazaar VCS data”. how will you do that?
[00:51] <arcfide> I don't need or want them to see all the intermediate commits and things that I track in Monotone, and indeed, there are some changes that I don't want to push upstream to them, but I do want to be able to create or generate a patch or push the changes that I want up to their branch.
[00:51] <arcfide> I'm in the same working tree.
[00:52] <arcfide> So, I have a folder SRFI/ that is simultaneously a Monotone Workspace and a Bazaar working tree.
[00:52] <arcfide> I make changes in that tree, and track those changes in different ways in the two systems.
[00:52] <arcfide> Up until now I haven't been using Bazaar at all, and I'm way out of date.
[00:53] <arcfide> So I have a working tree with a bunch of changes that I have made to it, uncommitted (to BZR's knowledge), but now I want to take my changes and send them upstream, and to do that I need to merge in their changes and figure out what conflicts.
[00:53] <arcfide> Am I doing things the wrong way?
[00:55] <arcfide> The branch that I was tracking before was called http://bazaar.launchpad.net/%7Eikarus-libraries-team/ikarus-libraries/srfi/, but now it seems to be lp:~scheme-libraries-team/scheme-libraries/srfi. It's the same project, though.
[01:07] <bignose> arcfide: sorry, was AFK
[01:07] <bignose> arcfide: one huge advantage of Bazaar is that, though a merge preserves all the revisions, the default log view doesn't show them.
[01:08] <bignose> arcfide: so there's no need to modify history for mere visibility reasons
[01:08] <bignose> arcfide: just merge all your stuff, and give the merge commit a useful summary
[01:08] <bignose> arcfide: then the user of that branch will see your merge commit with its useful message
[01:08] <bignose> arcfide: and, if they care, can choose to see the individual revisions merged
[01:09] <arcfide> Hm, I'm still not sure what you mean, but thanks!
[01:09] <bignose> arcfide: it means the “rebase common in other VCSen is virtually unnecessary in Bazaar
[01:09] <bignose> args
[01:09]  * bignose typing special characters badly
[01:09] <arcfide> Actually, I found something that works. If I do a bzr branch on the new branch, creating a fresh copy, and then move my Monotone settings into that working tree, Monotone will tell me everything that is missing or changed since I was working on it, and I can just merge from Bazaar that way, so everything seems cool.
[01:09] <arcfide> Rebase? I'm not familiar with that.
[01:10] <arcfide> I don't think we do that in Monotone land either.
[01:10] <bignose> arcfide: forget rebase then :-)
[01:10] <bignose> what is “bzr branch on the new branch”?
[01:10] <bignose> can you give these different things names so we can refer to them?
[01:10] <arcfide> Literally bzr branch <repo_url>.
[01:10] <arcfide> So, basically, the whole problem was that the upstream changed names.
[01:11] <bignose> I don't see how that's a problem.
[01:12] <arcfide> In Monotone, if you change branch names somewhere down the road, if you simply tell Monotone to grab the newer branch, it will following the changes through to the new branch and let you shift over to that new branch inside of the same workspace. I was trying to get the same effect in Bazaar, but it appears that branches are more disjoint things.
[01:12] <bignose> are you just looking for the command to tell Bazaar the new parent branch location?
[01:12] <arcfide> Basically, they switched to a new branch everything, and I couldn't just pull or merge anymore. It was giving me an error that the old branch didn't exist.
[01:13] <bignose> arcfide: okay, so you just specify the branch location
[01:13] <arcfide> I tried that, and it wouldn't work.
[01:13] <arcfide> You mean specify the new branch location, right?
[01:14] <bignose> arcfide: please, let's use names for these
[01:14] <bignose> make some arbitrary names and tell me which is which
[01:14] <arcfide> Using saved parent location: http://bazaar.launchpad.net/~scheme-libraries-team/scheme-libraries/srfi/
[01:14] <arcfide> bzr: ERROR: Unable to connect to target of bound branch BzrBranch6(file:///home/arcfide/code/srfi/) => http://bazaar.launchpad.net/%7Eikarus-libraries-team/ikarus-libraries/srfi/: Not a branch: "http://bazaar.launchpad.net/~ikarus-libraries-team/ikarus-libraries/srfi/".
[01:14] <arcfide> That's what BZR was giving me, I gave you the repo names above.
[01:15] <bignose> that's when you type what command?
[01:16] <lifeless> probably any
[01:16] <arcfide> bzr pull or merge.
[01:16] <lifeless> or at least update, commit, push and pull
[01:16] <arcfide> I think it was probably pull.
[01:16]  * arcfide searches his command history.
[01:16] <arcfide> Yes, pull.
[01:16] <lifeless> arcfide: bzr unbind
[01:16] <lifeless> arcfide: then bzr bind with the new upstream url
[01:16] <arcfide> Aaah.
[01:17] <arcfide> Okay, cool, thanks, I've learned something about BZR now. Thanks for your patience bignose.
[01:17] <bignose> arcfide: yes, I was going to modify your command to get it to remember the new location
[01:17] <bignose> as lifeless says, it's just a matter of telling Bazaar to update its remembered location to the new location
[01:18] <arcfide> I figured it was something simple like that.
[01:18] <bignose> okay :-)
[01:18] <bignose> glad to have helped.
[01:20] <arcfide> Um, so, when I try to commit, if my commit message has an "Unknown" in it, does that mean it is going to commit that file or just that it will ignore it?
[01:33] <spiv> arcfide: it will not include the unknown file in the commit (and will fail if you try "commit --strict")
[01:34] <arcfide> Aaah, okay.
[01:43] <arcfide> Thanks a bunch!
=== BasicPRO is now known as BasicOSX
=== med_out is now known as med
=== med is now known as medberry
[08:18] <vila> poolie: "We can possibly have dallas between the commands." Dallas ??? Is that a typo or am I missing a joke ?
[08:28] <fullermd> Hope it's not a joke.  It's so Belgium.
[08:38] <vila> fullermd: it appears that poolie was under attack by its spell-checker ;)
[09:04] <poolie> hi vila
[09:04] <poolie> there'sa session now about upcoming launchpad features in #ubuntu-uds
[09:04] <poolie> there'sa session now about upcoming launchpad features in #ubuntu-uds-tas
[09:04] <poolie> vila, jam, spiv, ^^
[09:04] <vila> poolie: ok, could we discuss 2.3.2/2.3.3 after that ?
[09:05] <poolie> "calving branching" too hey :)
[09:05] <poolie> you and me, or people here at uds?
[09:09] <vila> poolie: you and/or jelmer, the main point is to get feedback about the SRU and the failUnless, failIf deprecation fix diff size
[09:11]  * jelmer hears his name and wakes up
[09:11] <jelmer> vila: which issue is this?
[09:12] <poolie> vila, there's a session about lptools following this
[09:13] <vila> jelmer: see my mail on ML "bzr-2.3.2, SRU and conflicting tags"
[09:13] <vila> jelmer: roughly 2.3.2 fail the test suite with > 1000 errors
[09:13] <maxb> poolie: Btw, has there been any "Where to go and when to show up" info sent out for next week's bzr sprint? I've not seen any
[09:15] <poolie> ah, marianna probably missed you because (afaik) you don't need accommodation
[09:16] <poolie> basically turn up at the millbank tower before 9am monday
[09:16] <poolie> (or later if you want)
[09:16] <poolie> you will be expected
[09:18] <poolie> vila, i'm disappointed (not with you) that babune didn't catch this
[09:18] <poolie> i did actually look at it while you were away and found it down
[09:19] <vila> poolie: that's because it was *down* :)
[09:19] <poolie> i know
[09:19] <poolie> i know last time you said you turned off the hardware
[09:19] <vila> V. wasn't at ease leaving computers running without anybody to check for fire
[09:20] <poolie> :)
[09:20] <poolie> perhaps we can move it out of your house
[09:21] <vila> poolie: but the issue AIUI is that a python upgrade raised the issue so the slave needed to be upgraded to catch it anyway
[09:21] <vila> (or another job added on the master itself which is upgraded more regularly)
[09:21] <vila> but anyway, no vila at home, no upgrades
[09:25] <maxb> Thanks poolie - and yes, I'm only a tube journey away
[09:26] <vila> maxb: great, cu there ;)
=== hunger_ is now known as hunger
[09:32] <bialix> hi
[09:32]  * bialix is looking for vila, the master of configs
[09:32] <bialix> hey vila
[09:33] <vila> bialix: busy now, I'll try to answer but expect some lag
[09:33] <bialix> np
[09:34] <bialix> vila: ok
[09:38] <vila> bialix: hey, ask your question anyway ! :0
[09:39] <bialix> vila: I need to talk with somebody about qbzr.conf problems (bug #761535).
[09:39] <ubot5> Launchpad bug 761535 in QBzr "bzr-explorer forgets external diff tool" [High,Confirmed] https://launchpad.net/bugs/761535
[09:42] <poolie> vila, 2.3.3 sounds fine to me
[09:44] <vila> poolie: ok, I'll do that
[09:44] <vila> http://pad.lv/657550
[09:44] <ubot5> Launchpad bug 657550 in Launchpad itself "perform bzr merge in the UI" [Medium,Triaged]
[09:45] <vila> pad.lv/657550
[09:45] <thumper> vila: isn't hard
[09:45] <vila> hmm, so bug 657550 is still shorter
[09:45] <ubot5> Launchpad bug 657550 in Launchpad itself "perform bzr merge in the UI" [Medium,Triaged] https://launchpad.net/bugs/657550
[09:45] <vila> thumper: sorry, was just using a random bug to test the ubuntu bot
[09:45] <thumper> vila: :)
[09:46] <vila> thumper: argh, not implying the bug is random :-/
[09:46] <thumper> vila: and here I was thinking you'd fix it :)
[09:46] <vila> hehe
[09:47] <vila> poolie: if you could paste the channel where the next sessions is happening that would be great (makes it sooo easy to join including getting the audio)
[09:47] <poolie> it's on summit.ubuntu.com
[09:48] <jelmer> vila, it's in elod
[09:48] <vila> epic fail
[09:48] <poolie> yeah, elod
[09:48] <bialix> what is elod?
[09:48] <vila> #ubuntu-uds-elog
[09:48] <jelmer> bialix, it's the name of one of the rooms here at UDS
[09:48] <bialix> ah, great
[09:48] <vila> #ubuntu-uds-elod
[09:49] <vila> poolie, jelmer: I meant the channel *name* so I can click on it :)
[09:49]  * bialix has installed msvc2008 express russian version, it can compile bzr c extensions for py2.6
[09:50] <vila> bialix: \o/
[09:50] <bialix> compiling in russain is a lot of fun. ms did a very good job about printing russian messages to the console regardless of codepage
[09:50] <bialix> poor python
[09:51] <vila> bialix: so, I think you got a good handle on the problem, if you cache the whole file locally multiple times, incoherence is guaranteed
[09:51] <vila> bialix: that's why the bzrlib implementation re-read the config file before setting a single value
[09:51] <bialix> vila: yes, I want to talk about how to fix this mess now
[09:51] <vila> bialix: use the bzrlib implementation
[09:52] <vila> bialix: and while you're there, stop using embedded sections ;)
[09:52] <bialix> some parts of qbzr expects this caching behavior :-(
[09:52] <vila> bialix: why ?
[09:52] <vila> to avoid reading the file ?
[09:52] <bialix> vila: no way! only by mey dead corpse
[09:52] <vila> it's in the cache, it shouldn't make such a difference
[09:52] <vila> err, I meant the OS cache
[09:54] <bialix> vila: I've talked about embedded sections
[09:55] <bialix> wait! we don't have embedded sections yet! haha
[09:55] <bialix> we have just sections
[09:55]  * bialix has to teach himself to put smilie after each joke
[09:56] <bialix> vila: there was intent to write all changes to config file at once
[09:56] <bialix> should I keep that or should just write ever time the options changed... that's the question
[09:58] <vila> use the bzrlib implementation and it will write at each change
[09:58] <bialix> I think I should just go this way
[09:58] <vila> bialix: be also aware that new stuff I'm working on will *also* require some changes in your code anyway
[09:59] <bialix> oh, no! :-)
[09:59] <vila> I'll try to make this painless and provide some migration path but there are cases I just can't automate anyway so I'm now ~convinced that the most effective way to address the issues is to provide helpers instead of trying to automate all cases
[10:00] <bialix> sorry, I have no idea what are you talking about
[10:01] <bialix> I haven't followed your merge proposals
[10:06] <poolie> vila, jam, spiv, starting soon in elod
[10:06] <poolie> hi bialix
[10:06] <bialix> hi poolie
[10:06] <vila> poolie: already there
[10:07] <vila> bialix: how would you know then ! :D
[10:07] <jam> hi poolie
[10:08] <bialix> vila: know what? I'm subscribed to merge proposals but have no time to follow all of them
[10:09] <bialix> also I receive a lot of notifications about daily-ppa builds, they're a bit noisy
[10:09] <vila> bialix: know where we're heading so you can anticipate ;) Like... embedded sections are not needed to guarantee atomic changes (which AIUI is your main motivation)
[10:11] <bialix> sorry, I'm too dumb today. I just don't understand, perhaps I've missed something important
[10:13] <bialix> yesterday I had mid-term test in my English class. I have much worse result than I thought. My english skill is not good these days perhaps
[10:13] <vila> embedded sections are Evil: if you use one in the no-name section (i.e. branch.conf is just a no-name section) and call it 'qbzr' (for the sake of the example), then you can't have a section named 'qbzr' where you specify options that should apply to a 'qbzr' path
[10:14] <bialix> maybe we should just say that configobj is evil? joke joke joke
[10:14] <vila> bialix: hehe, don't get discouraged, it may just mean you're progressing by getting aware of your errors (as opposed to making errors without realizing it ;)
[10:15] <vila> bialix: well, almost, the problem is we din't clearly specified which parts we wanted to use and people went directly to configobj to use features that now conflict
[10:16] <vila> bialix: busy again, expect lag again
[10:16] <bialix> vila: about embedded sections: we don't use no-name sections in qbzr.conf
[10:17] <bialix> 12 tenses of english just kill me
[10:17] <vila> bialix: but you use one in branch.conf, that's the one that is the trouble for me
[10:17] <bialix> vila: oh, we have already talked about commit_data and have reached agreement I will remove it... sometimes soon
[10:18] <bialix> qbzr.conf is my headache now
[10:18] <vila> oh, I forgot about that, great !
[11:12] <poolie> vila, jam, talking about python versionsupport in -elod now
[11:12] <poolie> specifically dropping py2 from the cd in oneiric
[11:13] <poolie> not from the distro
[11:21] <mtaylor> poolie: you were right - easy_install launchpadlib works just fine now
[11:23] <poolie> hooray
[11:23] <poolie> i think it was broken but i might have fixed it
[11:23] <poolie> or someone else did
[11:23] <poolie> oh the thing with jenkins failures it turned out was actually from Brian
[11:23] <poolie> i replied to him
[11:23] <mtaylor> cool
[11:24] <mtaylor> do you remember what the issue was? something crazy?
[11:27] <poolie> https://issues.jenkins-ci.org/browse/JENKINS-1948
=== medberry is now known as med_out
[12:13] <poolie> jam, hi
[12:13] <jam> hi poolie
[12:13] <poolie> i'm just looking with eres at slow initial branching of gcc-licano into an empty repository
[12:13] <poolie> noticeably slower than going into a new standalone branch
[12:13] <poolie> this sounds familiar
[12:13] <poolie> there are many get_parent_map calls
[12:13] <poolie> but i thought this was fixed
[12:14] <jam> poolie: if you branch without a tarrget repo we issue a "give me everything request"
[12:14] <poolie> sorry, revital
[12:14] <jam> if you have a target repo
[12:14] <jam> we always _walk_to_common_revisions
[12:14] <poolie> then it checks what's there
[12:14] <poolie> right
[12:14] <jam> We talked about having a "is the repo empty" api
[12:14] <jam> never happened
[12:14] <poolie> or faster spanning out to discover this
[12:15] <poolie> ok ,https://bugs.launchpad.net/bzr/+bug/388269
[12:15] <ubot5> Ubuntu bug 388269 in Bazaar "many get_parent_map calls during walk to common revisions when branching into empty repository" [High,Confirmed]
[12:15] <jam> poolie: or using the target branch as a hint to what might be in the target repo
[12:15] <jam> (namely nothing)
[12:15] <jam> though this won't always be correct (new branches will always be at NULL:)
[12:16] <poolie> that's not a bad idea
[12:17] <poolie> ok thanks
[12:17] <Peng> What would that do if you were pulling into an empty branch even though the repo already has all the revisions?
[12:17] <poolie> we'll just let it run
[12:17] <jam> Peng: hence my point that it can only be a hint
[12:17] <Peng> :D
[12:17] <jam> (and one that doesn't cause things to explode badly)
[12:46] <stewart> are there any gui tools (esp for exploring history with annotate) that won't make me cry?
[12:46] <stewart> (this rules out bzr explorer and bzr-gtk's annotate)
[12:47] <awilkins> bzr qannotate ?
[12:48] <awilkins> Oh, hang on, bzr-explorer uses qbzr, doesn't it?
[12:48] <stewart> awilkins, looks like it
[13:23] <bialix> jelmer: should I package subvertpy 0.8.0 into windows installer? bzr 2.3 has packaged 0.7.5.
[13:42] <jelmer> bialix, 0.7.5 should still be fine for that version of bzr-svn
[13:43] <bialix> so, you don't recommend me to use 0.8?
[13:44] <jelmer> bialix, 0.8 shouldn't have anything 0.7.5 doesn't as far as the version of bzr-svn you're currently bundling goes
[13:45] <bialix> jelmer: can I have a very simple answer: y/n? I assume that I should use 0.7.5
[13:46] <jelmer> bialix: go for 0.7.5 if you're sticking to the same version of bzr-svn
[13:46] <bialix> svn version is lp:bzr-svn
[13:46] <bialix> i.e. your trunk
[13:47] <bialix> should I package specific version?
[13:47] <jelmer> bialix, if you use lp:bzr-svn you should use subvertpy 0.8.0
[13:47] <jelmer> but you shouldn't really use lp:bzr-svn in a release..
[13:47] <bialix> what should I use for 2.4b2?
[13:48] <jelmer> for 2.4b2 lp:bzr-svn is probably appropriate, there's no matching bzr-svn release yet
[13:48] <bialix> so then I should use subvertpy 0.8, right?
[13:54] <jelmer> bialix, yes
[13:54] <bialix> jelmer: thank you
=== med_out is now known as medberry
=== bigjools is now known as edbot
=== edbot is now known as bigjools
[14:44] <fullermd> Woof, up into the 71 millions on lplibrarian.
=== medberry is now known as med_out
[14:51] <jelmer> jam: are you happy for my per-file-graph branch to land? you mentioned in your comments that you were ok with it, but you didn't vote.
[14:56] <jam> jelmer: yeah, its fine
[14:57] <jelmer> jam: thanks!
[16:33] <fullermd> vila: Next release, should update the copyright date (still says -2010)
[16:36] <vila> fullermd: huh ? What ? WHere ?
[16:36] <fullermd> bzr version output's where I noticed it.
[16:37]  * vila whistles
[16:37] <fullermd> bzr script itself also has up to 2010.
[16:37]  * fullermd didn't look farther.
[16:38] <vila> argh, tricky setup for auto_update_copyright
=== Ursinha is now known as Ursinha-ohnomnom
[16:39] <vila> fullermd: thanks for the heads-up
[16:41] <fullermd> Yay, +karma.  Maybe now I can scream at people today and still wind up even.
[16:42] <vila> hehe
[16:47] <mgz> so, yelling at vila means you get to yell at other people too?
[16:47] <throughnothing> is there a way to view the diff of 2 separate branches in launchpad WITHOUT doing a merge proposal first?  I'd like to be able to send a link around and get feedback before doing a merge proposal
[16:47] <fullermd> mgz: Well, you gotta warm up first.  Otherwise you might strain your vocal chords, see.
[16:48] <vila> . o O (mgz: Perfect, I don't have to say it myself ;)
[16:49] <vila> throughnothing: no. But once you've made the proposal, you can just push your additional commits (or even different ones if you use push --overwrite), lp will happily re-calculate the diff
[16:49] <mgz> throughnothing: `bzr diff --old lp:<1> --new lp:<2>`?
[16:49] <vila> mgz: he want to send a link (presumably one showing the diff)
[16:49] <vila> throughnothing: is that ^ correct
[16:50] <fullermd> And the diff of two branches probably isn't what you really _want_; you want more a preview of the merge.
[16:50] <fullermd> (unless one branch is a strict superset of the other)
[16:51] <mgz> that's true.
[16:52] <throughnothing> mgz: thanks, yeah I know i can do this locally, I guess that'll have to do, just not as easy to get ppl to do that than to go to a link :)
[16:53] <mgz> getting feedback before a merge proposal seems a little over-cautious to me
[16:53] <mgz> just do an mp and say in the description you want feedback before doing more work on the branch
[16:53] <vila> throughnothing: mps are intended to cover getting feedback too
[16:53] <mgz> you can set the reviewers to specific people rather than the whole team for the project
[16:54] <mgz> (if you don't want to bug everyone)
[16:55] <throughnothing> mgz: ok, I just know that its not ready to be merged, and I know more stuff I have to do, but would like feedback on whats already done (for instance, I know i still need to add more tests)
[16:55] <throughnothing> but I understand your point as well
[16:55] <mgz> I do mps like that all the time :)
[16:55] <throughnothing> haha ok
[16:55] <throughnothing> i guess i can mark it as work in progress
[16:55] <throughnothing> or something similar
[16:58] <vila> throughnothing: yes, once you get feedback, marking as wip means... you're still working on it
=== Ursinha-ohnomnom is now known as Ursinha
[18:07] <briandealwis> Hi jelmer.  I'm trying to use bzr-git 0.6.0 with bzr 2.4b2 but it fails as "TypeError: As of bzr 2.4 Testament.__init__() takes a Revision and a Tree.".
[18:07] <briandealwis> So I thought I'd try from bzr-git from trunk, but it fails with "ImportError: No module named versionedfiles" at repository.py line 46 which does an import: "from bzrlib.plugins.git.versionedfiles import (GitTexts)"  and there's no definition for GitTexts
[18:08] <jelmer> briandealwis, hi
[18:09] <jelmer> briandealwis, fixed
[18:09] <briandealwis> great, thanks!
[18:09] <jelmer> I had a .pyc file around locally, which is why I must have missed it
[18:09] <briandealwis> ah right
[19:16] <mgz> dammit, forgot spell check
[20:13] <NielsD> hi
[22:17] <hbeck> hey, having an issue with qbzr package (qlog specifically):  bzr: ERROR: No module named configobj  You may need to install this Python library separately.
[22:18] <hbeck> quick google says this issue has been seen before but I'm not sure what the fix was/is
[22:20] <hbeck> I have bzr 2.3.1-0 and qbzr 0.20.0-1
[22:27] <hbeck> also, python-bzrlib shows "/usr/share/pyshared/bzrlib/util/configobj/configobj.py" installed.
=== Ursinha is now known as Ursinha-afk
[22:58] <maxb> hbeck: Could you please check versions with "dpkg -l bzr python-bzrlib qbzr" - 2.3.1-0 does not look like a real version to me
[22:59] <hbeck> bzr                             2.3.1-0~bazaar1~lucid2
[22:59] <hbeck> I just chopped the end off
[22:59] <hbeck> python-bzrlib                   2.3.1-0~bazaar1~lucid2
[22:59] <hbeck> qbzr                            0.20.0-1~bazaar1~lucid1
[23:21] <hbeck> maxb: that help any?
[23:26] <chx> why is it that though i have not configured an editor in bazaar.conf, i do not have $VISUAL and $BZR_EDITOR set and $EDITOR is set to nano I *still* get vi?
[23:47] <maxb> hbeck: Hmm. I thought we'd got rid of all these problems. Maybe the qbzr package isn't new enough
[23:48] <maxb> huh, this is probably something fixed in 0.20.1