[03:27] <GungaDin> I can't check out a branch because bzr raises an exception saying 'readline' is not defined...
[03:27] <GungaDin> any ideas?
[03:27] <GungaDin> (bzr version is 2.1.1)
[09:29] <poolie> spiv, is https://bugs.edge.launchpad.net/bzr/+bug/496813 now fixed? just wondering about the strange state
[09:37]  * spiv looks
[09:48] <spiv> Closed, thanks.
[10:04] <rom1> Hi all,
[10:05] <rom1> I have some questions about how to hide the "failed to load extensions" warning
[10:05] <poolie> ok
[10:05] <poolie> spiv, not closed for 2.0?
[10:05] <rom1> I have tried the ignore_missing_extensions in bazaar.conf
[10:06] <rom1> but the warniongs still appear... Do i have to do something else ? (Bazaar (bzr) 2.1.1 installed with packaging lucid)
[10:07] <ronny_> hi
[10:07] <ronny_> whats a good way to make bzr ignore missing whoami settings in unittests
[10:08] <mwhudson> ronny_: 'use bzrlib's TestCase' is probably one answer
[10:08] <ronny_> mwhudson: im using py.test, and anyvc is wrapping up much of bzr
[10:09] <poolie> rom1, i'm a bit suprised, but you should file a bug
[10:09] <poolie> ronny_, run the tests with $HOME set to something holding a .bazaar/bazaar.conf that's not your real one
[10:09] <rom1> ok, thx poolie
[10:09] <poolie> or BZR_HOME
[10:10] <ronny_> any way to supply it in python code?
[10:10] <mwhudson> ronny_: http://pastebin.ubuntu.com/464435/
[10:12] <ronny_> hum, seems to depend on testtools
[10:12] <mwhudson> yes
[10:14] <ronny_> seems i'll need some nasty special cases for bzr
[10:15] <spiv> poolie: weird that I failed to see that!  Closed for 2.0 as well now.
[10:26] <rom1> Hou, found what my probleme was :
[10:27] <rom1> In fact, i do a branch or any operation on a distant server in bzr+ssh
[10:27] <poolie> ronny_, are you running bzr inprocess?
[10:27] <rom1> the warning comes from the distant server and not the local bzr...
[10:27] <poolie> ah ok
[10:27] <rom1> which means that i have to put the ignore_missing_extensions my distant config
[10:28] <poolie> fraid so
[10:28] <poolie> you can't install the extensions there?
[10:28] <poolie> which platform is it?
[10:29] <rom1> debian etch
[10:29] <rom1> we have backported the bzr 2.1. Have to check the compilation
[10:29] <poolie> it would be cool if you can publish that backport
[10:29] <poolie> if it's not already in the debian.org backprots
[10:30] <rom1> gonna check with my packager
[10:56] <ronny_> poolie: yup
[10:57] <ronny_> poolie: its for the anyvc bzr backend
[11:34] <ronny_> hum
[11:34] <ronny_> if bzr wont listen i will just leave it out of ci
[11:35] <lifeless> won't listen ?
[12:45] <ronny_> lifeless: whops, that was a figure of spech
[12:46] <ronny_> lifeless: whats a good way to set up bzr for one global whoami entry that isnt affected by the user home
[12:46] <ronny_> (from the api)
[12:53] <lifeless> ronny_: well, change the user home, then use the global config object as 'bzr whoami' does.
[12:54] <ronny_> lifeless: can i do that from code so i can make it part of the test setup
[12:55] <spiv> ronny_: yes, set HOME or BZR_HOME in os.environ
[12:55] <spiv> ronny_: take a look at what bzrlib.tests.TestCase does
[12:57] <ronny_> hum, looks nasty
[13:35] <parthm> hello. how can i make the user-reference html? i tried `make docs` but that doesnt seem to build the user-reference.
[13:35] <parthm> i am using 2.2 branch
[13:38] <spiv> make docs-sphinx, IIRC
[13:42] <parthm> spiv: thanks. make doc/en/user-reference/index.txt seems to create the rsts. then i did make html from within doc/en. yes, the sphinx style docs are generated.
[13:42] <parthm> spiv: looks like basic html docs can't be generated for user-reference.
[14:12] <dipnlik> hi, anyone here using bzr rebase? tried it with --dry-run but it did make the modifications, is this a known bug?
[18:58] <JoshBrown> I've accidentally set my whois to 'Josh Brown joshbrown@site.com <joshbrown@site.com>' and done several commits. I've now fixed the whois, but is it possible to change the commits?
[19:05] <maxb> Not easily, and not at all if they have been shared with other people
[19:07] <Meths> Could combine uncommit with shelve ?
[19:11] <maxb> That falls under than heading of "Not easily" :-)
[19:11] <Meths> Yes :)
[19:12] <Meths> Couldn't he just use the pull reference given by uncommit if there is an interspersed commit from another person?
[19:12] <Meths> If he's feeling particularly masochistic
[19:13] <maxb> That would pull the old versions of preceding commits
[19:13] <maxb> uncommitting someone elses revisions is a big no-no anyway
[19:24] <basic`> is there any way to debug some strange errors i'm getting with bzr?  it looks like bzr is giving a permission denied for the public key of my user, but i'm able to ssh to the remote machine with my key
[19:36] <JoshBrown> Ah, well I'll take that as a 'no' - I suppose it isn't *such* a big deal anyway.
[19:59] <basic`> any ideas?
[19:59] <basic`> according to the auth.log on the master/host box, the session authenticates fine
[19:59] <basic`> and then it disconnects
[20:00] <basic`> it looks like bzr is disconnecting the thing, but it's outputing a permission denied (publickey,gssapi-with-mic). error
[20:00] <basic`> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[20:50] <james_w> poolie: are you around?
[20:50] <poolie> hi, i am actually
[20:51] <james_w> hi
[20:51] <james_w> poolie: https://code.edge.launchpad.net/~rom1-chal/bzr-builder/reporting_conflict_from_merge/+merge/30127 <- could you look at analyse_conflicts there and tell me if you know of a better way to achieve that?
[20:52] <poolie> ah interesting, i think he was online before
[20:53] <poolie> well i probably wouldn't put it inline in the exception of course...
[20:54] <james_w> I'm thinking of showing the "bzr log" for the revisions, rather than just printing the developers, but I imagine that parsing the annotate text isn't ideal either way.
[20:54] <poolie> no, it's not
[20:54] <james_w> indeed
[20:54] <james_w> and doing it lazily would be better
[20:54] <poolie> if you peek inside the implementation of annotate i think there's an easy structured form
[20:58] <poolie> james_w, so i'd probably work from _expand_annotations, at least
[20:58] <poolie> that should be easily parseable
[20:58] <james_w> yeah
[20:58] <poolie> i think ideally this would be separated into something people could use in other bzr applications
[20:58] <poolie> like in tarmac or pqm
[20:58] <james_w> I don't like having to construct a Revision like that
[21:00] <poolie> mm, that's weird
[21:01] <poolie> gannotate works on the uncommitted changes without needing that
[21:02] <poolie> hm, apparently in the same way
[21:02] <poolie> that's a bit gross but perhaps it needs to be fixed in the core
[21:03] <poolie> i guess that's where he got the idea from
[21:05] <poolie> hi svaksha
[21:06] <james_w> parsing the lines seems kind of necessary, but we can't rely on MERGE-SOURCE and TREE, but without them we might get confused
[21:08] <poolie> maybe he/she copied them from gannotate
[21:08] <james_w> yeah
[21:09] <james_w> I just mean in general, we can query a tree for conflicted files, but not for conflicted chunks
[21:10] <poolie> right
[21:10] <poolie> it would be better to do the merge and annotation together
[21:10] <poolie> if you did a weave merge you'd get that built in
[21:10] <james_w> hmm
[21:10] <james_w> that could work
[21:11] <poolie> and i think also in structured form
[21:11] <james_w> this is certainly better than the "OH NO CONFLICTS!!" we have now, so I'd be inclined to merge some version of this and go for incremental improvement.
[21:12] <poolie> i'd like to see this in core
[21:12] <poolie> maybe not run by default...
[21:12] <poolie> it's kind of hard to tell where to put things that don't justify a whole plugin but that could be generally useful
[21:13] <poolie> it seems like the ideal here would be something like
[21:13] <poolie> 'bzr conflicts --why' to give you this summary
[21:13] <poolie> listing the revisions and authors involved in each file
[21:14] <james_w> yes
[21:15] <poolie> https://bugs.edge.launchpad.net/bzr/+bug/606465
[21:15] <poolie> btw i set up http://pad.lv/606465 for a shorter form
[21:15] <james_w> do you think taking the intersection of (revisions touching lines inside conflict markers) and (revisions after the LCA of the branches) would be the correct thing to do?
[21:16] <james_w> (is LCA the right choice there?)
[21:16] <james_w> oh, nice
[21:16] <james_w> and thanks for the bug
[21:16] <james_w> shall I file one for --why?
[21:16] <poolie> yes, and please point to this
[21:17] <poolie> right, the strange thing about annotating conflicts is that they're not guaranteed to be the ones that actually "caused" the conflicts
[21:17] <poolie> i guess they will give you a decent clue
[21:18] <poolie> enough it's worth trying it out
[21:22] <dipnlik> can anyone help me use difffork as my bzr diff tool?
[22:46] <sven_oostenbrink> Asked this before, but I have to ask again.. What is the best way to make merges of common libraries in between distinct projects?
[22:46] <sven_oostenbrink> I have right now 3 projects, one is a framework, the other two are implementations of that framework
[22:46] <sven_oostenbrink> Now, in the two implementation projects, we occasionally find and fix bugs
[22:47] <sven_oostenbrink> I want to somehow merge those fixes back in to the framework project, and from there, send it as an update to the other implenmentation project
[22:47] <sven_oostenbrink> implementation as in, it implements the framework...
[22:47] <sven_oostenbrink> Now, this merging is so far good for a nice migraine everytime I try it
[22:48] <sven_oostenbrink> I need to somehow be able to filter specific directories, but AFAIK, bzr can't do that
[22:48] <sven_oostenbrink> so I go to the framework project, do a merge from that implementation project, then one by one filter out that which is project specific, and then commit the merge.. but everytime it gets more complex, and more error prone..
[22:50] <sven_oostenbrink> So I'll have to ask again, isnt there a bettere way to do this? some sort of directory filter maybe? like, merge, but automatically filter (as in, ignore those directories) all that is ".........."
[23:16] <StoneCypher> I would like to merge some of my subversion repositories while I transition to Bazaar, but I'm unwilling to let go of their histories.  It's fine if I lose their old version numbering.  Is this supportable?
[23:17] <StoneCypher> that is, I have repos in the form lib1, lib2, lib3, and i'd like to transition to lib/lang/lib1, lib/lang/lib2, lib/lang2/lib3, etc
[23:27] <maxb> sven_oostenbrink: I do not understand your terminology. In my mind, a framework is something other projects depend on, not something that other projects implement.
[23:28] <sven_oostenbrink> maxb: Fair enough, the two other projects depend upon that framework..
[23:28] <maxb> StoneCypher: Are you sure you want to combine all those libraries in a single bazaar tree, which is always branched/tagged/checked-out as a single entity?
[23:29] <StoneCypher> max: yes
[23:29] <sven_oostenbrink> Thing is, we fix bugs in that framework also directly in those two projects.. Makes it a hell of a lot easier to do so.. but then, how can I get those fixes back in the framwork branch?
[23:30] <maxb> StoneCypher: then, I think the answer is to convert them all to Bazaar separately, and then look at the 'bzr join' command to assemble the combined tree
[23:31] <StoneCypher> oh, ok
[23:32] <maxb> sven_oostenbrink: sounds to me that the framework should be a subtree within the other projects, and that fixes should be made in the framework branch whereever possible
[23:32] <StoneCypher> does bzr join weld B into A, or does it create C from A and B?
[23:32] <maxb> when not possible, I suppose I'd cherrypick the fixes from the other projects back into the framework branch
[23:32] <maxb> StoneCypher: the first
[23:34] <sven_oostenbrink> maxb: yeah, but since that makes it at best very very hard to make those changes.. Every time you want to make changes to the framework, you'd have to open up another project, make sure you would not accidentally change stuff in the framework that is in the project tree, etc...
[23:35] <sven_oostenbrink> In that case, its easier actually to just do what I do now.. Make the changes in the project, then merge all project changes to the framework branch, before committing that merge, remove all project changes, and then commit
[23:35] <sven_oostenbrink> But even that is tedious..  There has to be a better way..
[23:42] <StoneCypher> maxb: so, i create a bazaar repo under the desired final name, then one per library to be transitioned, then -join them to the final, one at a time?
[23:46] <sven_oostenbrink> Would it be possible for BZR to include a filter like this?