[00:01] <lifeless> bjp_: those are daemons
[00:09] <bjp_> so will configuration file support be dropped eventually? it seems like it has a lot more options than just serve-branches
[00:10] <rar> hmpf. okay, I now see how to fix it, but still not sure *why* r4781 broke my code
[00:15] <rar> ah, now I do. before stopTest was being run before the final finally, which replaces the TestCase __dict__ and now it's being run afterwards
[00:15] <rar> not the easiest diff in the world to read.
[00:27] <bjp_> what is causing this? : Unsupported configuration: PasteDeploy not available, but loggerhead appears to be behind a proxy.
[00:38] <lifeless> bjp_: you haven't installed python-paste-deploy
[00:40] <lifeless> rar: sorry :)
[00:40] <lifeless> what was syour code doin that this has broken
[00:44] <rar> replacing a test with another one, but  keeping the original test around for later
[00:44] <maxb> If a svn repository has switched from one layout to another during its lifetime, is it likely to completely confound even bzr-svn's sophisticated mappings?
[00:44] <lifeless> rar: ?!
[00:44] <rar> you also fixed the never-not-applicable bug though, so I could remove my workaround for that
[00:44] <lifeless> maxb: I don't know - give it a go
[00:44] <maxb> Well, it's dumping crash reports at me :-)
[00:45] <lifeless> maxb: file bugs ;)
[00:45] <maxb> against the mindset of people who rearrange their svn repositories? :-)
[00:45] <lifeless> yes:)
[00:46] <rar> basically it's a thing for raising a test result without having to run the test, as some of them blow up in violent, suite-destroying ways
[00:47] <lifeless> rar: I am totally confused; is there code I can see?
[00:47] <lifeless> I don't understand how a test can destroy a suite
[00:47] <rar> well, test_breakin_harder likes hanging the process
[00:48] <lifeless> it should be a lot more robust nowadays, I hammered on it recentl.
[00:48] <rar> and there are some others that blow the stack on ironpython, and I've yet to track down what exactly is making jython die
[00:49] <bjp_> ic
[00:49] <rar> at any rate, it's a hack, but a useful one for the moment
[00:49] <lifeless> rar: oh, you're working on other vms - cool
[00:51] <jelmer> maxb, it shouldn't cause a crash at least, at most it should cause your history to be thinner than you would expect
[00:53] <rar> anyway, the rev is fine, it just meant I needed to discover attrs_to_keep (understanding all of bzrlib.tests is... not a one sitting thing)
[00:55] <lifeless> rar: I still don't get why you need to poke at that level
[00:55] <rar> well, another for instance, currently if any of the test modules has an import that fails, the whole test run stops
[00:56] <rar> some of the test modules import bz2 or signal or something, that other imps don't have
[00:56] <lifeless> file a bu on that please
[00:56] <lifeless> (the test suite not running)
[00:57] <rar> I'm not really sure it's a bug, and the best fix I have has issues
[00:57] <lifeless> I'd still like a bug :)
[00:57] <lifeless> taggest selftest
[00:57] <rar> the bits of this that aren't nasty workarounds I will try and get in
[00:59] <rar> anyway, monkeypatched in a bit so it registers as a kind of failure instead, eg:
[00:59] <rar> http://float.endofinternet.org/temp/bazaar_j_noncpython_bt.test_#bt.test_smart
[00:59] <rar> (and the wide red bars just under that)
[02:37] <thumper> is there a way to add a new file with the history of an existing one?
[02:37] <thumper> for example having one file that you are breaking into two?
[02:37] <thumper> or is that not possible?
[02:40] <RAOF> thumper: You mean something like "bzr cp old new", right?  I'm fairly sure that's not (yet) supported, but is something that might be worked on at some point.
[02:41] <thumper> RAOF: thanks
[04:07] <spiv> jml: the room is open, btw
[06:43] <naoki> Hello.
[06:43] <naoki> Is there any plan to translate help strings? (ex: bzr help, bzr help commit, etc...)
[06:44] <SuperMMX> does the bug #375013 fixed?
[07:05] <mwhudson> SuperMMX: no
[07:18] <SuperMMX> mwhudson: thanks, just asking
[07:18] <mwhudson> SuperMMX: np, i understand it's trickier than you might thing
[07:18] <mwhudson> *think
[10:16] <bialix> Hi GaryvdM
[10:17] <bialix> GaryvdM: I won't mind if you rename trunk2a
[10:18] <GaryvdM> bialix: Ok - I'll do that now.
[10:18] <bialix> wait a sec
[10:20] <bialix> GaryvdM: I've just replied to your mail
[10:20] <bialix> I have concern re stacked btanches.
[10:20]  * GaryvdM goes to read it
[10:20] <bialix> GaryvdM: does they will re-stack automatically?
[10:20] <bialix> should we upgrade lp:qbzr/0.14 as well?
[10:22] <GaryvdM> poor roots - lol
[10:22] <GaryvdM> bialix: I think that stacked branches on launchpad will automaticly point to the renamed branch.
[10:22] <GaryvdM> But I'll try double check
[10:23] <bialix> poor roots (c) fullermd
[10:23] <bialix> GaryvdM: ok, perhaps we just need to try and if things going wrong we need to rename them back
[10:23] <GaryvdM> yes
[10:24] <GaryvdM> bialix: But I'll try find out anyway before I make the change
[10:27] <bialix> ok
[10:34] <bialix> GaryvdM: I've sent mail to luks and ask about admin rights for you
[10:34] <GaryvdM> Thanks
[10:36] <bialix> let's increase bus factor ;-)
[10:40] <GaryvdM> bialix: renaming trunk did break the stacked branches, so I reverted it.
[10:40]  * GaryvdM => lunch
[10:41] <bialix> GaryvdM: can you write it in mail please, so our beloved core devs will be aware of this problem?
[10:41] <bialix> bon appetit
[10:41] <GaryvdM> yes - I will.
[12:33] <RenatoSilva> verterok: hi, we had a big blackout here, sorry
[12:33] <RenatoSilva> verterok: I worked in the test failures, so I improved the code: http://bazaar.launchpad.net/~renatosilva/bzr-java-lib/encoding-fixes/revision/206
[12:34] <RenatoSilva> verterok: tests are all ok here, both in mvn and eclipse: http://img195.imageshack.us/img195/2136/testsok.png
[12:35] <RenatoSilva> verterok: would be nice if you merge rev206 in your branch to test in your environment
[12:36] <GaryvdM> RenatoSilva: I was reading the irc log, and I saw that you said it you be nice if qlog has a search function.
[12:36] <RenatoSilva> GaryvdM: yes
[12:36] <RenatoSilva> GaryvdM: it has, but not for what I want
[12:36] <RenatoSilva> GaryvdM: it does not search in the actual changes
[12:37] <GaryvdM> RenatoSilva: Ah - It does integrate with bzr-search. Install that, index your branch, and it will also search in the file content. :-)
[12:38] <RenatoSilva> GaryvdM: file content or file changes?
[12:39] <GaryvdM> Um - not sure. Same as what bzr-search does. I think content.
[12:40] <RenatoSilva> verterok: also, your hudson server successfully built the bzr-java-lib-xp (encoding fixes) :)
[12:41] <RenatoSilva> GaryvdM: what I want is for example bzr search "print 'hi'", then get all the --revisions-- which have added or removed such a line
[12:42] <GaryvdM> RenatoSilva: I see. - Please will you log a bug in bzr-search for that.
[12:42] <RenatoSilva> GaryvdM: you are a bzr-search developer?
[12:43] <GaryvdM> No - but I'm getting in to it.
[12:43] <GaryvdM> I've submitted my first merge proposal.
[12:44] <GaryvdM> RenatoSilva: lifeless is the author. If you read the comments in the code, you will see that he was thinking about that idea.
[12:57] <bialix> GaryvdM: have you looked at https://code.launchpad.net/~craighewetson/qbzr/tag_from_qlog/+merge/13096 ?
[13:02] <RenatoSilva> GaryvdM: bug 480684
[13:11] <thrope> hi - is it possible to add something to .bzrignore to ignore symlinks
[13:11] <bialix> thrope: nope
[13:12] <thrope> ok thanks
[13:13] <rar> presumably a precommit hook could filter them out though
[13:13] <bialix> yep, but you need to explicitly ignore them then
[13:17] <hno> Is there some way to subscribe to early notifications when a new version have been uploaded to launchpad?
[13:19] <bialix> new version of what?
[13:19] <hno> bzr
[13:21] <bialix> there is bazaar-announce ML, not sure it will serve you well in the case of "early" notifications
[13:22] <hno> No, that's late.. want to get notified when the release is available for download so I can push it to the Fedora updates-testing repository, ready to be pushed out as an update when the update is formally announced.
[13:24] <bialix> I'm monitoring main bzr ML for the messages like this: bzr 2.0.x gone gold
[13:24] <bialix> you need to ask for core devs maybe they can suggets something or improve their process
[13:25] <hno> for example 2.0.2 was uploaded to launchpad a week ago, but not yet announced.
[13:26] <hno> Guess I need to do the same..
[14:00] <sivang> hi all
[14:01] <sivang> I want to swipe my whole office to use bzr
[14:02] <sivang> should I setup a bzr server on my machine to poeple could branch my code and push code to it ?
[14:02] <sivang> I don't want a central repository
[14:03] <sivang> I see on the docs there's no special need for a server, but everybody here is used to svn
[14:03] <sivang> so..
[14:06] <awilkins> sivang, Why not peruse http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html and see about persuading them that way?
[14:07] <sivang> awilkins: I'd rather have bzr working for me, show them how easy it is and then be accepted without too much persuation
[14:08] <awilkins> sivang, I'm using bzr on a few projects that still use SVN servers ; you can demonstrate all the advantages without divorcing yourself from the SVN server
[14:08] <sivang> awilkins: right, I will read now the documentation about this
[14:20] <sivang> awilkins: where the general guidlines and starting documention for bzr ? is James Black still working on docs ?
[14:23] <smartgpx> sivang: try http://bazaar-vcs.org and then use the Documentation link at the top
[14:24] <bialix> sivang: no, James Black no more participate in Bazaar project
[14:24] <bialix> now Ian Clatworthy is our champion
[15:13] <jsmith23> is there a way to shelve all changes? instead of going through one by one?
[15:14] <gioele> jsmith23: bzr shelve --all
[15:14] <smartgpx> bzr shelve --all ?  (bzr help shelve)
[15:15] <jsmith23> gioele: smartgpx: sure enough, first line of the help
[15:15] <jsmith23> thank you
[15:36] <gioele> does anybody use Eclipse to develop bzr?
[15:48] <gioele> how come the launchpad plugin now uses launchpad_username instead of [Launchpad] inside authentication.conf?
[15:50] <bialix> gioele: I think it uses both
[15:53] <gioele> bialix: it just complained that the login name was not set (it has been in auth.conf since ages). Using "bzr launchpad-login gioele" created a brand new entry in bazaar.conf (my ~/.bazaar/ is bzr-managed ;))
[15:54] <bialix> without looking into lp code I'd say entry in bazaar.conf used as flag
[15:54] <bialix> or maybe for lp: access?
[16:09] <gioele> I found some off-by-one whitespace problems in builtins.py, should I correct them and send a patch?
[16:27] <gioele> is there a way in bzrlib to send a message to the user? I'd like to ask her "Are you sure to continue? [Y/n]"
[16:29] <bialix_> gioele: see ui package
[16:29] <bialix_> there is ask_boolean
[16:34] <gioele> bialix: thank you! (get_boolean, btw)
[16:35] <bialix> my memory as sieve, silly me!
[18:02] <maxb> Is there any programmatic way to query the format of a *remote* branch?
[18:03] <beuno> maxb, via http you can get it, so I expect you need to look at a specific file
[18:03] <LarstiQ> maxb: `bzr info remote` or use BzrDir
[18:04] <maxb> LarstiQ: bzr info lp:bzr, for example, just says format: unnamed
[18:04] <beuno> maxb, because it goes via bzr+ssh
[18:04] <beuno> if you use http:..
[18:04] <beuno> it will tell you the truth
[18:04] <beuno> it;s something about the smart server
[18:04] <maxb> hm
[18:05] <LarstiQ> maxb: how about -v?
[18:06] <maxb> LarstiQ: Just says the format is a remote one
[18:06] <maxb> Is there any way to override ~/.bazaar/bazaar.conf settings on the command line?
[18:06] <beuno> you need to fallback to vfs to read it
[18:06] <beuno> maybe you can specify that in the API call
[18:09] <maxb> Hmm. HOME=/dev/null bzr info lp:bzr
[18:09] <maxb> hacky, but works
[18:09] <maxb> Is is a shame there isn't a lphttp:
[18:11] <fullermd> You can use nosmart+bzr+ssh (and I think nosmart+lp too), which falls back to VFS methods.
[18:12] <fullermd> Yeah, nosmart+lp expands through to nosmart+bzr+ssh
[18:35] <maxb> fullermd: yay, that's exactly what I need, thanks :-)
[19:45] <Shirik> Hello all. I have a question: I have a situation where I just finished merging in some changes from what we will call our "trunk" into a development branch. I went to push it to that branch and got an error. After investigation, I determined someone already tried to make the same change to the branch. So I pulled and got diverging branches as expected, but what I want to do is
[19:45] <Shirik> drop everything that is not mine, rather than merge
[19:45] <Shirik> Is there a way I can do this?
[19:46] <Shirik> I know that's the correct solution, I'm just not sure how exactly to go about doing it
[19:46] <Shirik> Basically I have diverging branches and I just want to kill one of the branches
[19:50] <Shirik> So currently I have a revision showing up as "missing" and I just want to kill that revision so it never gets merged in, I guess that's what I want to do
[19:53] <bialix> Shirik: push --overwrite
[19:53] <bialix> or uncommit
[19:54] <Shirik> that worked, thanks
[19:59] <thumper> if 2.1.0b2 is gold, why isn't it in the bzr-beta-ppa?
[20:01] <thumper> also the bzr nightlies don't seem to be building either
[22:02] <gioele> I'm writing a test for a little addition I made to cmd_commit. I expect bzr to ask me a question via get_boolean. How can I check that?
[22:35] <lifeless> gioele: there is a testing UI factory
[22:35] <thumper> lifeless: hi
[22:35] <lifeless> gioele: where you can supply the inputs it gets
[22:35] <thumper> lifeless: who is responsible for the PPAs?
[22:35] <lifeless> spyuz
[22:35] <lifeless> spyuz
[22:35] <lifeless> bah
[22:35] <lifeless> soyuz
[22:36] <thumper> lifeless: who uploads the bzr stuff to the ppa?
[22:36] <thumper> as the daily and beta are out of date
[22:36] <thumper> and I've been bitten by a bug that jam has fixed
[22:36] <thumper> bzr keeps crashing on me
[22:36] <thumper> is very frustrating
[22:36] <lifeless> jamesw  does the daily, johnf is working on fixing the beta, currently sorting out a bunch of packaging differences to make it more scriptable
[22:37] <lifeless> jamesw is on leave
[22:37] <thumper> I may just grab bzr.dev and use that
[22:37] <thumper> for now
[22:37] <thumper> :(
[22:37] <thumper> not done that yet on this computer
[22:37] <thumper> lifeless: what dependancies to I need to build bzr.dev fully?
[22:38] <lifeless> apt-get build-dep bzr
[22:38] <lifeless> + python-pyrex
[22:39] <lifeless> bbiab
[22:44] <gioele> lifeless: I had a look around that but I could not find method of TestCommit that I could use to assert "now this question is asked and a Y/n prompt is presented to the user"
[23:02] <thumper> lifeless: poos
[23:02] <thumper> lifeless: my crash is still in bzr.dev
[23:02] <lifeless> thumper: whiss
[23:11] <thumper> lifeless: I'm getting something like bug 461643
[23:12] <thumper> lifeless: but this is with a clean bzr.dev and I ran make
[23:12]  * thumper files a bug anyway
[23:14] <thumper> WTF???
[23:15] <thumper> lifeless: I thought I was running my new bzr.dev, but it seems it isn't
[23:16] <thumper> g'ah
[23:16] <thumper> ok, is fixed in dev
[23:18]  * thumper needs new deb badly
[23:33] <lifeless> gioele: I will try to look it up for you, at a meeting at the moment
[23:34] <gioele> lifeless: thank you
[23:35] <gioele> lifeless: anyway, I'm leaving but I sent a RFC on a tiny patch on the mailing list; I asked the same question in that mail
[23:39] <taxilian> morning all
[23:39] <taxilian> I have a plea for help =]
[23:40] <taxilian> Long story short, a local branch got accidently bound to a remote branch, and then updated; all the changes in the local branch were lost
[23:40] <taxilian> the local branch was in a shared repository, so hypothetically the data should still be in there somewhere
[23:40] <taxilian> does anyone know how I could find/get to it?
[23:41] <fullermd> They're there whether it's a shared repo or not.
[23:42] <fullermd> You can probably use the heads plugin to take a guess at the revid.
[23:42] <taxilian> even though the branch itself is now bound to a different branch?  and updated?
[23:42] <taxilian> *looking for heads plugin*
[23:42] <fullermd> And then use pull to set that as the head (after unbinding of course)
[23:43] <fullermd> If you bound and update'd, but then didn't revert or anything, it's actually sitting right there as a merge rev, but there's no way to sweet-talk the UI into telling you that revid.
[23:43] <taxilian> the plugin is called "heads"?
[23:43] <fullermd> It's included in bzrtools these days.
[23:44] <taxilian> ahh; I see it.  running it now.
[23:44] <taxilian> thank you
[23:48] <taxilian> I think I found the revision I need; how do I get to it now?  using bzr pull?
[23:52] <taxilian> actually, no, it isn't listed there
[23:52] <taxilian> none of the heads I need are listed :-(
[23:52] <taxilian> rather none of the listed heads are the one I need
[23:55] <fullermd> Are you running head --dead-only?