[00:41] <MTecknology> so.. is there any nice intuitive docs for using bzr-fastimport?
[00:42] <MTecknology> bazzar-vcs.org/BzrFastImport explains hwat it is but not how to use it..
[00:54] <spiv> MTecknology: bzr help plugins/fast-import
[00:55] <spiv> (or maybe "bzr help plugins/fastimport", actually...)
[00:58] <poolie> hi spiv
[00:58] <poolie> hi bialix, igc, MTecknology
[01:04] <igc> hi poolie
[01:05] <MTecknology> spiv: oh - thanks
[01:06] <MTecknology> poolie: hi
[01:06] <fullermd> Oh, thanks for mentioning fastimport.  Reminds me I wanted to prod the cvs2svn port maintainer about upgrading...
[01:06] <igc> MTecknology: see http://doc.bazaar-vcs.org/plugins/en/fastimport-plugin.html
[01:06] <MTecknology> spiv: now - how about a bzr-fastdeb tool?
[01:06] <MTecknology> igc: thanks
[01:06] <igc> and http://doc.bazaar-vcs.org/migration/en/data-migration/index.html
[01:11] <spiv> MTecknology: what do you mean by "fastdeb"?
[02:04] <xnox> Hello I've realised I've been working in the wrong branch =) how can I pull just the working tree from the other branch? Can I shelf it on one branch and unshelf in another working-tree/branch
[02:06] <spiv> xnox: perhaps "bzr merge --uncommitted" can do what you need
[02:08] <xnox> spiv: Awesome thanks =)
[02:28] <xnox> how can I push to parent branch instead of push branch without retyping it?
[02:29] <spiv> bzr push :parent, IIRC
[02:29] <xnox> spiv: thanks =) is it part of revspec?
[02:29] <spiv> And if you did "bzr push :parent --remember", then subsequent pushes of that branch you can do just "bzr push".
[02:29] <xnox> manual?
[02:30] <xnox> spiv: no I don't want that =) parent is svn repo. Push is bzr for me =)
[02:30] <xnox> Push is to lp ;-)
[02:31] <spiv> I'm not sure where it's documented.  The defined aliases are :parent, :submit, :public, :push, :this, and :bound.
[02:32] <spiv> Hmm, I don't think it is documented.  There's probably a bug about that...
[02:34] <spiv> It's bug 337834
[02:35] <spiv> igc: any progress on alias (:parent, etc) docs?
[02:39]  * xnox feels like he know bzr zen now =) working with undocumented tricks ;-)
[02:39] <poolie> xnox: spoilers welcome
[02:39] <SamB_XP> spiv: is that one of mine ?
[02:40] <igc> spiv: still on my todo list. Maybe this week all going well
[02:53] <spiv> SamB_XP: that bug?  It doesn't have your name on it, but I suppose if you wrote a patch no-one would complain... ;)
[02:57] <xnox> Oooh Can I write a patch? =)
[02:58] <xnox> I'll poke around bzr code and try all of them ;-) Black-box testing for perfect documentation =)
[03:01] <spiv> xnox: well, you can just read the code rather than guess :)
[03:01] <spiv> xnox: bzrlib/directory_service.py has the relevant code :)
[03:03] <xnox> ok I'll see what I can come up with ;-)
[03:05]  * spiv -> lunch
[03:09]  * igc lunch
[04:13] <jfroy|work> hey people
[04:13] <poolie> hello jfroy
[04:13] <jfroy|work> I'm getting an core dump running a plan diff command in a working tree because of a missing revision (probably a ghost)
[04:14] <jfroy|work> This being on machine B
[04:14] <jfroy|work> and the branch having been acquired through bzr-svn
[04:14] <jfroy|work> so, basically, to be expected
[04:14] <jfroy|work> the question is, how do I 1) get a list of ghost revision IDs
[04:14] <jfroy|work> 2) figure out in which branch a particular revision ID lives (on machine A which should have said rev ID)
[04:15] <jfroy|work> poolie: and hi !
[04:15] <poolie> hm
[04:15] <jfroy|work> Also, as a suggestion, core dumping on a missing revision when doing a simple diff -> going to scare people away
[04:15] <poolie> !!
[04:15] <jfroy|work> really should handle it better
[04:15] <poolie> yeah
[04:15] <poolie> do you mean actually dumping a core file?
[04:15] <poolie> or just a python stacktrace?
[04:16] <jfroy|work> right, python stack trace
[04:16] <jfroy|work> not an actual interpreter core dump
[04:16] <jfroy|work> that'd be *very* scary :p
[04:16] <poolie> that's what i thought
[04:16] <jfroy|work> sorry for the confusion :.
[04:16] <jfroy|work> * :/
[04:17] <jfroy|work> Though I consider unhandled exceptions in bzr as "crashes"
[04:17] <jfroy|work> they're just as unhelpful as plain old crashes to users
[04:17] <jfroy|work> anyways, on the matter at hand...
[04:17] <jfroy|work> bzr check lists the the number of ghost revisions
[04:17] <jfroy|work> but I can't seem to find a command to actually give me the revids
[04:18] <poolie> jfroy: i agree, we should never show python crashes to user - this is the documented policy, that whenever this happens, it's a bug
[04:18] <jfroy|work> although the backtrace does have one, which seems kind of silly -- "oh just use unhandled missing revision exceptions to find the ghost revision IDs!"
[04:18] <poolie> however, in 95% of cases, there is actually some more important underlying bug
[04:19] <jfroy|work> yeah
[04:19] <poolie> so showing a crash is an appropriate way to represent it
[04:19] <poolie> not trying to fob you off but the best thing is probably to either look for or file a bug
[04:19] <poolie> it may already be known
[04:19] <poolie> about the ghost revision crash
[04:19] <poolie> and that bug may have better info than i have in my head
[04:19] <jfroy|work> Oh I know why I'm getting it.
[04:19] <jfroy|work> It's a ghost.
[04:20] <jfroy|work> The bug already exists to handle them better in various commands.
[04:20] <jfroy|work> well, bugs
[04:20] <jfroy|work> I just want to get a list of them so I can turn around and find who has those revs...
[04:24] <jfroy|work> mm, well that worked; used the revid from the backtrace with bzr log -c -r revid:<id>
[04:24] <jfroy|work> from a random branch
[04:24] <jfroy|work> it found it, got me the branch nick, and I pulled that branch in
[04:24] <jfroy|work> need a better workflow than that -- ghosts are going to be common for bzr-svn users
[04:24] <jfroy|work> might be worth a plug-in...
[04:56] <igc1> bbiab
[05:13] <xnox> I have wrote some help for the urlspec and URL directories
[05:13] <poolie> nice
[05:14] <xnox> I have tried automating code just like with protocols and it showed up three directories
[05:14] <xnox> : Easy access to remembered branch locations
[05:14] <poolie> jam, how do you get into the breakin debugger on windows?
[05:14] <xnox> lp: Launchpad-based directory service
[05:14] <poolie> igc ^^?
[05:14] <xnox> and
[05:14] <xnox> deb: whitch uses Vcs-* fields.
[05:15] <xnox> But where did the deb: directory came from?
[05:15] <xnox> I don't remember installing such plugin and it sounds awesome
[05:15] <poolie> probably bzr builddeb?
[05:16] <spiv> xnox, poolie: yes, bzr-builddeb
[05:18] <xnox> Well I never new about it..... =( now with my improved documentation I found out about it =_
[05:18] <xnox> =)
[05:59] <RAOF> It seems that lp:do/0.8 has had a failed upgrade at some time in the past, so when I try to upgrade it now it complains that backup.bzr exists.  How can I fix this?
[06:01] <spiv> RAOF: connect to it with an sftp client (lftp is a good one) and delete that dir and its contents.
[06:03] <spiv> RAOF: lftp -e 'rm -r backup.bzr' sftp://bazaar.launchpad.net/~do-core/do/0.8
[06:04] <RAOF> Aaah.  It's the full specification that's strange.
[06:05] <spiv> Yeah.
[07:06] <poolie> spiv, in question 93050 and i think a couple of others recently we've seen things hang during a long body fetch
[07:06] <poolie> there may be nothing in common and there's not much to go on
[07:07] <poolie> but i wonder if it's more than a coincidence
[07:10] <spiv> poolie: hmm, the only other case I recall seeing recently was vila's VM at the sprint
[07:10] <spiv> (hi vila!)
[07:11] <vila> hey :) Don't mention that VM hangs, not now, let me get some more coffee first :)
[07:11] <spiv> That case was due to misconfigured network(s)
[07:11]  * vila kicks babune hard hoping to un-hang gentoo and hardy and jaunty
[07:11] <vila> Hi all
[07:12] <spiv> And in that question 93050 there was definitely a misconfigured network (dropping all ICMP!), pity that correcting that didn't make the problem go away :)
[07:12] <vila> by the way, if anybody landed some patch related to log, the tests are failing for LOCALE=C (the part we don't run anymore on PQM)
[07:13] <spiv> It does seem fairly clear from the description that it's something to do with their firewall, which makes me think that it's not bzr's fault, but maybe there's something we can do to make us less susceptible?
[07:13] <poolie> hi vila
[07:13] <spiv> vila: I think r4868
[07:13] <poolie> vila, maybe it was igc sponsoring marius's patch?
[07:16] <vila> yeah I suspected so... or not, I seem to recall a discussions about tests during the review... I was hoping some long due refactoring there had started :-P
[07:18] <poolie> spiv oh my mistake
[07:18] <poolie> i thought there was another one where they hadn't specifically mentioned a firewall thought
[07:28] <spiv> poolie: hmm, it's confusing, 93050 is a dupe of 93043, although I realise now they misfiled that one against bzr-upload
[07:29] <spiv> poolie: but in a reply to 93043 they say "If i disable ufw firewall completely, then, i am able to do checkout from the external network."
[07:29] <spiv> er, 93045 I mean.
[07:46] <vila> LC_ALL=C ./bzr selftest -s bb.test_log -s bb.test_commit is the recipe to get the 4 errors
[07:51] <poolie> vila, file a bug for igc, if you haven't already
[07:51] <vila> poolie: sure
[07:51] <vila> poolie: do you intend to land or work on https://code.edge.launchpad.net/~mbp/bzr/progress-output/+merge/14944 ?
[07:52] <vila> if it's 'land' I can help, if it's 'work' let's put it back into wip (Work in progress)
[07:53] <poolie> vila, it has test failures
[07:53] <poolie> which i should fix, but i suck
[07:53] <vila> lol, so wip ? Too many things are already falling from my plate to honestly propose help here :->
[07:58] <poolie> nag me
[07:58] <poolie> i'll do it now
[08:27]  * igc1 dinner
[08:56] <poolie> vila, sanity check wanted re that review
[08:56] <poolie> how about giving log code two file like objects, one for unicode and one for bytes (for the diffs)
[08:57] <poolie> it essentially does this internally but it gets them by peeking inside what it assumes is a codec wrapper
[08:57] <vila> let me get the code
[08:58] <vila> argh, marked wip I presume, it went out of the active review page :-/
[08:59] <vila> so, without the code, two file objects sounds weird, but if it's through an API, I think it's fine and if that's what the code needs anyway then that's the way to go
[09:00] <poolie> i know
[09:00] <poolie> there's a bug about that
[09:00] <vila> one aspect I like a lot about TDD is that it gives more users to the code which is the best way to find the good design and APIs
[09:00] <poolie> mm
[09:01] <vila> ha, found it back lp:~mbp/bzr/progress-output right ?
[09:01] <poolie> right
[09:01] <poolie> you can still use the url you pasted above
[09:02] <poolie> like this http://pastebin.ubuntu.com/337132/
[09:03] <vila> hmm, my gut feeling looking at that is: ui.ui_factory.make_output_stream(encoding) is all that is needed
[09:03] <vila> each command can then decide how many file objects it wants
[09:04] <poolie> where?
[09:04] <vila> http://pastebin.ubuntu.com/337132/
[09:04] <poolie> i mean
[09:04] <poolie> are you suggesting i do that in cmd_log?
[09:04] <vila> log -p is really a special beast AIUI, other commands will use a single file object, only log -p needs two
[09:05] <poolie> right
[09:05] <poolie> so i'm just doing this as a special case in log
[09:05] <vila> yup, as long as the buffering is right
[09:06] <vila> make_output_stream can then handle the special cases (tty, redirected, etc), the caller is still responsible for the encoding
[09:07] <poolie> hm
[09:07] <vila> does that fly ?
[09:07] <poolie> oh you're saying one level for just 'give me a stream'  and then another doing encoding?
[09:07] <vila> make_output_stream takes an encoding parameter
[09:08] <poolie> right
[09:08] <vila> encoding_type, sorry, hmm
[09:08] <poolie> so you're suggesting moving that into say make_encoded_output_stream?
[09:08] <poolie> it takes both
[09:08] <poolie> it can be eg 'utf-8', 'replace'
[09:09] <Kamping_Kaiser> can i delete a branch from a remote host? (a branch i've pushed in the past which isn't needed anymore)
[09:09] <vila> no, just using it, AIUI log requires different encodings for the commit messages and the diffs
[09:10] <vila> Kamping_Kaiser: bzr doesn't provide a command for that, but you can delete the directory on the remote host (especially if you use a shared repo there)
[09:10] <Kamping_Kaiser> vila: ah, so i have to ssh to the host and rm -f the branch? no worries. cheers.
[09:11] <vila> Kamping_Kaiser: that's it, you're welcome
[09:11] <Kamping_Kaiser> thanks :)
[09:12] <poolie> vila https://bugs.edge.launchpad.net/launchpad-code/+bug/489036  btw about wip mps
[09:16] <vila> poolie: comment added there
[09:19] <vila> poolie: also since you're touching _setup_outf(), if you could call it at the right time so that using Command objects become less painful... you'll be my hero :-)
[09:19] <vila> By 'less painful' I'm thinking about tests or plugins that override commands and have to call _setup_outf() explicitly when building Command objects
[09:20] <vila>  # XXX: is the caller supposed to close the resulting object?
[09:20] <vila> yes
[09:20] <vila> poolie: ^
[09:21] <vila> # XXX: this does not handle the case of writing part of a line
[09:21] <poolie> heh
[09:21] <vila> caller responsibility, trying to address it there will be nightmarish
[09:21] <poolie> thanks lazyweb
[09:22] <vila> lazyweb ? Literally a social network of lazy people ?
[09:23] <poolie> mm, the term for asking humans something that you could look up yourself but are to lazy to
[09:23] <poolie> too*
[09:24] <vila> hmm, found it, yeah, got it
[09:24] <poolie> i'd like to land this but i'd be happy to look at that next
[09:24] <vila> sure
[09:28] <poolie> ok
[09:28] <poolie> incremental diff posted - should be ok but will you have a quick look?
[09:30]  * vila reading
[09:35] <vila> poolie: hmm, why not just self.to_exact_file = to_exact_file in LogFormatter.__init__ ?
[09:35] <vila> and callers will fail if they try to use it without setting it
[09:37] <vila> jelmer: hi :)
[09:38] <poolie> (phone)
[09:39]  * vila cries, vbox's bug is making scroll wheel unusable :-(
[10:00] <bialix> heya
[10:01] <jelmer> hey vila :-)
[10:01] <jelmer> 'moin bialix
[10:02] <bialix> moin jelmer!
[10:02] <bialix> bonjour vila!
[10:02] <vila> hi bialix
[10:04] <poolie> escudero going down soon
[10:28]  * shyam_k trying out loggerhead
[10:28] <shyam_k> but gets the message "internal server error" as i try 127.0.0.1:8080/
[10:29] <shyam_k> http://pastebin.ca/1706723 thats what "./serve-branches ~/Scheme" says where i have bazaar set to ~/Scheme
[10:32] <shyam_k> what is wrong here? i just untarred the logger head source and ran that command
[10:32] <shyam_k> as said in its README
[10:35] <shyam_k> ./serve-branches ~/Scheme/.bzr shows the directories inside the control directory but not the files..
[10:36] <shyam_k> ah ic.. thats just the response it gives for any random directory..
[10:43] <poolie> vila: should i send it?
[10:45] <vila> poolie: hmm, why not just self.to_exact_file = to_exact_file in LogFormatter.__init__ ?
[10:45] <vila> and callers will fail if they try to use it without setting it
[10:45] <vila> you didn't answer that :)
[10:46] <vila> but anyway, if the actual patch works and given it has already been approved, I don't want to delay it further, if you have enough info to do another submission, please land that one
[10:46] <poolie> mm
[10:46] <poolie> misguided conservatism
[10:46] <vila> and replace some commas by periods in the sentence above, its unreadable :)
[10:47] <vila> mm, from me or from you ?
[10:47] <poolie> me
[10:47] <poolie> leaving the old path
[10:48] <poolie> k
[10:48] <poolie> almost 10
[10:48] <poolie> will fix that and send it tomorrow
[10:48] <vila> poolie: excellent
[10:48] <vila> enjoy your night !
[10:49] <vila> hmm, is there some example somewhere to use pqm for remote branches >
[10:49] <vila> s/>/?/
[10:49] <poolie> no
[10:49] <poolie> i couldn't work it out
[10:49] <vila> LOL
[10:49] <poolie> ping spiv for some docs?
[10:49] <poolie> i meant to do that
[10:50] <vila> spiv: your patch to pqm is great !!!!
[10:50] <vila> spiv: Please add doc so all patch pilots can enjoy it !
[10:50] <vila> :D
[10:52] <shyam_k> what i am trying to do is to see a web frontend of my local bazaar files..
[10:52] <shyam_k> bzr serve said its listening on port 4155 but then localhost:4155 just goes on "Transfering data from localhost.."
[11:11] <vila> poolie, spiv: So the trick is to specify --public-location and --submit-branch and have a locations.conf setup so that it provides pqm_email... a bit tortuous
[11:12] <vila> oh, and use http: not lp:
[11:12] <vila> and --ignore-local
[11:13] <vila> and then... it just works :D
[11:15] <sepult> i'm trying to checkout the grub trunk from savannah, but bzr
[11:15] <sepult> complains it's not a branch
[11:15] <sepult> how does one check it out ?
[11:38] <sepult> hey
[11:39] <sepult> anyones awake ?
[11:41] <spiv> vila: yeah
[11:42] <spiv> vila: I basically just hacked until it did just enough to work and then went back to doing something more directly productive
[11:53] <vila> sepult: if it complains, it means you're not using the right url
[11:53] <vila> spiv: yeah, I can understand that, but a one line example in the readme or somewhere would have addressed that ;)
[12:24] <bignose> is Ian Clatworthy here?
[12:24] <bignose> or someone who manages <URL:http://planet.bazaar-vcs.org/> feeds?
[12:24] <Peng> igc: You have a customer. :D
[12:24] <bignose> a post from Ian C is messed up, it has an empty URL for the article link.
[12:25] <Peng> Yeah, that's been going on for a while. You can go to http://bazaarvcs.wordpress.com/ directly.
[13:36] <vila> poolie, spiv: I knew I read a working example somewhere: bug #487458
[16:05] <rubbs> If I'm making small changes in the docs to fix bugs (mostly just broken links) should I be putting something in the NEWS file? I haven't been, but I wasn't sure what should go in there.
[16:27] <bialix> rubbs: just file a merge proposal and reviewer or patch pilot will help you with this question
[16:34] <rubbs> bialix: ok thanks, should I do something about the ones that were already merged?
[16:34] <bialix> rubbs: no, if they're merged you can forgot about 'em
[16:35] <bialix> if you don't plan to continue improve them of course
[16:37] <vila> rubbs: The rule is that bugs are mentioned in NEWS when they imply a "significant" change in bzr usage, doc is a bit different but sometimes fixing a broken link can change the whole experience...
[16:37] <vila> rubbs: so use common sense and do as you feel, the reviewer can still disagree if needed :)
[16:40] <rubbs> vila: cool thanks a lot. that helps. That also means I've been correct so far as well.
[16:40] <vila> rubbs: sure !
[16:40] <james_w> rubbs: you could put one NEWS item that summarised the improvements, possibly with the list of bugs
[16:40] <vila> rubbs: anwyay, the meta-rule is: when in doubt, ask the question in the cover letter
[16:41] <rubbs> vila: james_w: cool, will do in the future. Most of my changes have been rather small nearly trivial stuff so far, so no need to add to NEWS
[16:42] <Peng> IMO, enough trivial changes can add up to something NEWSworthy.
[16:43] <rubbs> maybe what I'll do is find all the doc bugs that have been done in the last few weeks and add them in (since the bzr-doc team has been created)
[16:44] <rubbs> under a "various bug fixes" heading or something
[16:44] <rubbs> It might be too much to list all the bug #'s even.
[16:55] <jam> morning all
[16:57] <bialix> hi jam
[16:57] <jam> hi bialix
[16:58] <bialix> jam, can you suggest some tool to log memory consumption of the linux system?
[16:59] <bialix> I need to log it to file, not to GUI
[17:00] <jam> bialix: you might check 'trace.debug_memory()'
[17:01] <jam> bialix: I also have this script: http://paste.ubuntu.com/337403/
[17:01] <jam> which spawns a command that you specify
[17:02] <jam> and then sits and polls the memory consumption every N seconds
[17:03] <rubbs> bialix: another hackish way to do it might be to use the 'free' command in a shell script like: watch -n 1 free >> log.txt
[17:04] <rubbs> not sure how well that would work though
[17:04] <bialix> ok, I'll try to experiment with this, thanks guys
[17:05] <rubbs> bialix: np. good luck!
[18:37] <james_w> anyone know why t.path2id would return an id, but t.get_file_text(that_id) would say NoSuchFile?
[18:37] <james_w> symlink?
[18:46] <jam> james_w: file deleted on disk but not removed via the api?
[18:47] <james_w> oh, this is a revision tree I think
[18:47] <jam> or directory
[18:47] <james_w> thanks
[18:48] <james_w> also, I currently have a long running bzr process
[18:48] <jam> `I usually think of NSF being for a physical file that we failed to read
[18:48] <jam> not a missing file in a tree
[18:48] <james_w> strace appears to show it opening the dirstate and reading it, then copying some working tree files to limbo then repeating
[18:49] <james_w> any idea what it it might be doing?
[18:49] <james_w> it is a large tree
[18:49] <jam> if you are looking at a symlink or a directory, I would expect you to get back an empty string for the content
[18:50] <jam> from what I can see
[18:50] <jam> james_w: if you are opening dirstate, then it isn't a revisiontree
[18:50] <jam> james_w: do you have the traceback?
[18:50] <james_w> oh, two issues
[18:51] <james_w> http://launchpadlibrarian.net/35785267/merge-issue is the traceback for the NSF
[18:52] <jam> ah, hmm.. I missed the translation
[18:52] <jam> RevisionNotPresent => NoSuchFile
[18:53] <jam> james_w: can you drop into the debugger, and give me the output of "pp repo_desired_files" ?
[18:53] <jam> hmm.. I guess it is supposed to be [('changelog-20090616010821-kgsodu5lhwu5pm2i-145', 'james.westby@ubuntu.com-20090905094641-seag0w0dagb6q3m1') ]
[18:53] <jam> so...
[18:54] <jam> my best guess right now is that you have corrupted data
[18:54] <jam> something thinks that its text should be found at X, but X isn't present in the repo
[18:54] <jam> i certainly can't guarantee that
[18:56] <james_w> maybe it's just bzr-builddeb looking in the wrong repo
[18:57] <james_w> no, that's not it
[18:58] <jam> vila: ping for great justice
[18:59] <jam> james_w: well the line: fix_ancestry_as_needed
[18:59] <jam> concerns me
[18:59] <jam> given that it looks like you are doing surgery on stored data...
[18:59] <james_w> I don't think it means what you think it means :-)
[18:59] <jam> inconceivable
[18:59] <jam> :)
[18:59] <james_w> granted, using ancestry to mean two things is likely to do that :-)
[19:00] <james_w> ok, your suspicion of corruption may be correct
[19:00] <james_w> % bzr branch lp:debian/sid/cwidget debian
[19:01] <eric_f> I'm running Loggerhead 1.17, is there something I'm missing about getting the syntax highlighting support enabled?
[19:01] <james_w> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', "Absent factory for ('column_definition.cc-20090616010821-kgsodu5lhwu5pm2i-43', 'james.westby@ubuntu.com-20080120093711-23aliq7ki0te4l21')")
[19:01] <vila> jam: NACK, dinner time, I'll read the logs and be back later (if time permits)
[19:01] <james_w> hi vila
[19:01] <james_w> eric_f: do you have pywotsit installed?
[19:01] <jam> vila: just thinking about trying to get a win32 host running from babune again, and thought I'd chat with you about it.
[19:02] <jam> can wait till tomorrow
[19:02] <james_w> eric_f: or "pygments" as it is more commonly known?
[19:02] <eric_f> james_w: probably not, is that the answer?
[19:02] <james_w> I think that's the library used to do it
[19:02] <eric_f> james_w: can that be installed via aptitude?
[19:02] <james_w> I think so
[19:02] <Peng> eric_f: python-pygments
[19:02] <jam> eric_f: apt-cache search pygments
[19:03] <Peng> eric_f: Should start working automagically once you install Pygments and restart Loggerhead.
[19:05] <eric_f> james_w, Peng, & jam: thanks! That all worked
[19:08] <jam> vila: also, wondering the status of fixing the selftest is broken on win32 stuff
[19:08] <jam> I'll put together a patch if you can't, at least for the "test suite should run" part
[19:32] <vila> jam: sooo, I couldn't work on bug #492561 today but first thing tomorrow !
[19:33] <jam> vila: I already have a patch that at least lets "bzr selftest" run
[19:33] <jam> I'm putting it up for review now
[19:33] <jam> It doesn't fix the failure
[19:33] <jam> but at least I can get a failure :)
[19:33] <vila> jam: I too thought about adding a win32 host to babune *but* babune is acting like crazy these days
[19:34] <vila> jam: yeah, I saw your patch, you're right, put that up for review but let's leave the bug open
[19:34] <jam> sure
[19:34] <vila> I'll start from that anyway
[19:35] <vila> I'm quite sure the failure is closely related to the ones I have from PQM or under emacs depending on details. The crux is that we lack tests :-) But it's damn hard to test these things :-/
[19:35] <vila> Let's have a call tomorrow, there are other things I like to discuss too anyway. Deal ?
[19:35] <vila> jam: ^
[19:36]  * vila hears family calling again
[19:37] <jam> vila: sure
[19:37] <jam> vila: enjoy yourc family time
[19:37] <jam> your
[19:38] <jam> vila: if you get a chance to approve: https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-win32-test-imports/+merge/15829
[20:50] <druido> hi, I've got this error message: bzr: ERROR: The method _generate_inventory is not supported on objects of type CHKInventoryRepository.
[20:51] <druido> I can't find anything on the web about it
[20:51] <druido> does anybody know what it means?
[21:05] <druido> this is what i've done: i've splitted a subtree of my branch using the following commands (say 'trunk' is the main branch and 'foo' is the subtree to be splitted):
[21:05] <druido> cd trunk
[21:05] <druido> bzr split foo
[21:05] <druido> cd ..
[21:06] <druido> bzr join —reference trunk/foo
[21:06] <druido> bzr commit
[21:07] <druido> now, whenever i add a file to trunk and try to commit, or whenever i try to revert a change in trunk i get
[21:07] <druido> bzr: ERROR: The method _generate_inventory is not supported on objects of type CHKInventoryRepository.
[21:08] <druido> i'm using bzr 2.0.1 and my repository format is 2a
[21:08] <jam> druido: I'm pretty sure that 2a format repos *don't* support subtrees
[21:08] <jam> so you can't join --reference in them
[21:09] <jam> I'm a bit surprising it isn't failing earlier with a 'supports_subtree' check
[21:09] <druido> ah, ok, in fact that command didn't seem to have any effect
[21:10] <druido> is it possible to change the format to fix the problem?
[21:13] <druido> i've repeated the steps again right now, with a new repository and it works as i've explained
[21:15] <druido> (of course, i forgot to add 'cd trunk' before 'bzr commit' in the steps above)
[21:29] <druido> ok, here is a minimal set of commands to reproduce my problem:
[21:29] <druido> bzr init-repo foo-repo
[21:29] <druido> cd foo-repo
[21:29] <druido> bzr init trunk
[21:29] <druido> mkdir trunk/foo
[21:29] <druido> bzr add trunk
[21:29] <druido> bzr commit trunk -m "Added foo."
[21:29] <druido> bzr split trunk/foo
[21:29] <druido> bzr join --reference trunk/foo
[21:29] <druido> mkdir trunk/bar
[21:29] <druido> bzr add trunk
[21:30] <druido> It seems that, without bzr join, the above works ok
[21:30] <druido> The problem is, I have given that command, and I've got no error :(
[21:30] <vila> jam: passing around, https://code.edge.launchpad.net/~jameinel/bzr/2.1.0b4-win32-test-imports/+merge/15829 approved with minor tweaks
[21:32] <vila> jam: and to clear any ambiguity, adding a win32 host is high on my list and I agree that any regression in the test suite there is as critical as anywhere else (but I've yet to re-activate the OSX slaves :-/)
[21:33] <jam> druido: without 'bzr join' bzr add of a sub branch is a no-op, I believe
[21:34] <druido> ok, but it fails even if i try bzr add with new files
[21:34] <druido> i should be able to add trunk/bar in the example above, or am i missing something?
[21:35] <jam> druido: well 'bzr add sub/branch' is saying add all the files in sub/branch, not add sub/branch to the current branch
[21:37] <druido> sorry, maybe i've not used the cleanest syntax in my commands above
[21:38] <druido> after the split and join, i cd into trunk and perform 'mkdir bar; bzr add'
[21:38] <druido> that gives me the error i've mentioned
[21:38] <druido> i don't understand why
[21:40] <jam> druido: after you've done the 'join' the content is broken
[21:40] <jam> it just doesn't catch it early
[21:40] <jam> as it should
[21:40] <druido> ok, at least now i understand why
[21:40] <jam> I don't know why it lets you get into that state by running join
[21:40] <jam> it shouldn't
[21:41] <druido> is there a way to fix it? i've tried bzr check and bzr reconcile without success
[21:41] <jam> bzr revert
[21:41] <jam> I think will undo it
[21:41] <jam> if not
[21:41] <jam> rm .bzr/checkout ; bzr co .
[21:41] <jam> sort of thing
[21:41] <jam> but be careful with the last one
[21:41] <druido> bzr revert gives me the same error
[21:41] <jam> k
[21:42] <jam> mv .bzr/checkout .bzr/checkout-broken
[21:42] <jam> bzr co .
[21:44] <jam> druido: are you back?
[21:44] <druido> yes, i was trying your last idea
[21:44] <druido> it seems to work
[21:45] <jam> k, I wasn't sure how much you caught with the irc disconnect
[21:45] <druido> after checking out, i've got a conflict on the subbranch i've splitted
[21:45] <druido> "Conflict adding file foo.  Diverted to foo.diverted."
[21:46] <druido> but, after resolving it, it seems to work fine
[21:46] <druido> now i can add and revert
[21:49] <druido> great, thank you!
[21:49] <druido> should i file a report somewhere?
[21:50] <jam> yeah, https://bugs.launchpad.net/bzr
[21:50] <jam> there may already be a bug report for this
[21:50] <druido> ok, i'll search for it
[21:50] <jam> but something along the lines of "bzr join --reference breaks 2a format trees"
[21:54] <poolie> hello all
[21:54] <poolie> i'll file an rt for bignose's issue
[21:56] <jam> hi poolie
[21:57] <druido> i've found this: https://bugs.launchpad.net/bzr/+bug/369923 but the error is different
[21:58] <jam> ugh
[21:58] <jam> On Windows
[21:58] <jam> copy adir\ file
[21:58] <jam> well
[21:58] <jam> copy adir\ target
[21:58] <jam> ends up copying all files in adir
[21:58] <jam> into a *single* destination file 'target'
[21:58] <jam> similar to
[21:58] <jam> cat adir\* > target
[21:58] <druido> i'll add a comment to bug 369923 then
[21:59] <jam> not exactly what I expected
[22:14] <druido> ok, i've added a comment to bug 369923
[22:14] <druido> thanks for your help, folks!
[22:17] <igc> morning
[22:23] <RenatoSilva> how to hack the history? I passed certain time calling the rabbit as fox
[23:53] <poolie> james_w: around? need anything from us?
[23:53] <poolie> we need to chew on the udd thread a bit more.
[23:54] <james_w> poolie: I reported a bug today, I don't know whether it needs some more info first
[23:55] <james_w> I know the error message is usually not very helpful in understanding what is wrong