[00:00] <abentley> igc: restarted
[00:30] <javierder> bueno, yoh!
[00:30] <beuno> javierder, hey. I see you've been keeping up the work on bzr-gedit  :)   Do you have an ETA for the next release?
[00:31] <javierder> beuno, yes, next friday
[00:31] <beuno> I'm flirting with the idea of packaging it, but I'd like to get rid of the bzr-gtk dependencies before I do
[00:31] <beuno> is that close by on the roadmap?
[00:32] <javierder> that's actually not in the roadmap. but i don't think much code is needed. I'll check it now.
[00:32] <beuno> javierder, cool  :)   I think that if it's packaged, you might get more users testing it
[00:33] <javierder> ok, greta
[00:33] <javierder> *great
[00:33] <beuno> no real hurry, just wanted to check in to see what the situation was
[00:42] <javierder> beuno, check it now if you want :)
[00:49] <beuno> javierder, looks good. Did you test it withough bzr-gtk installed?
[00:53] <javierder> beuno, not exactly, but i tested it changing the module it tries to import. if the plugin can't find bzrlib.plugins.gtk some commands won't work.
[00:53] <beuno> javierder, good enough. I'll look into packaging it then
[00:53] <javierder> ok, great!
[00:58] <lifeless> fbond: I'd really like docs for what you do today; such things will help clarify what automation is most useful.
[01:58] <fbond> lifeless: Okay, I'll put something brief together.
[02:04] <lifeless> fbond: it doesn't have to be hugely polished
[02:09] <fbond> lifeless: Being temporary documentation, I wouldn't think so :)
[02:09] <fbond> lifeless: I guess it's all temporary documentation, though.
[02:10] <lifeless> :)
[02:39] <abentley> lifeless: In my pull change, there will be no error if the specified revision id is in the target, but not the source.  This doesn't cause any tests to fail.
[02:44] <lifeless> abentley: ok, land it then
[03:03]  * igc lunch
[05:12] <lifeless> woo
[05:12] <lifeless> looks like this will be it
[05:18] <lifeless> taking a short break while this test tests
[05:24] <awmcclain> Has anyone configured bzr-email to work with gmail? I have the gmail-branch, but it's not sending and I'm not seeing any errors in .bzr.log
[05:42] <lifeless> abentley: around ?
[05:42] <abentley> lifeless: Yup
[05:42] <lifeless> abentley: I am about to start rewriting fetch.py for VersionedFiles; I am hoping you can get your rich-root conversion fixing patch landed asap :)
[05:42] <lifeless> so that I can layer on your work
[05:43] <abentley> I hope so too.  It's in igc's hands now.
[05:44] <igc> abentley: I approved that an hour or so ago I think
[05:45] <igc> make that 30 minutes :-)
[05:45] <igc> just some comment tweaks and all good now
[05:45] <abentley> Okay.
[05:46] <lifeless> I'm submitting my new streaming api for review too
[05:46] <lifeless> it may textually collide with your patch I think, but in a trivial fashion
[05:46] <lifeless> the next phase will be more...dramatic
[05:47] <abentley> lifeless, igc: Cool.  I'll do that now.
[05:53] <abentley> lifeless: It's in progress.
[05:57] <abentley> lifeless, poolie: I have just added a "My Todo" tab to Bundle Buggy.  It lists all your merge requests that haven't been merged or rejected.
[05:57] <lifeless> nice, thanks
[05:59] <abentley> You're welcome.
[06:00] <abentley> It should list everything that's gotten a resubmit, or is pending review, or has been approved.
[06:00] <abentley> Let me know what you think.
[06:12] <abentley> lifeless: Will your work have a significant impact on the reconcile code?
[06:13] <lifeless> abentley: I'll be leaving a thunk behind
[06:13] <lifeless> abentley: but ideally, yes, I will be touching everything
[06:14] <abentley> Reconcile is the remaining piece of this inventory_sha1 stuff.
[06:14] <lifeless> yeah
[06:14] <abentley> I've started on tests, but perhaps the fix should wait.
[06:16] <lifeless> I think we won't collide
[06:17] <lifeless> I can leave reconcile till last
[06:18] <abentley> Okay.
[06:43] <fullermd> Is 1.4 blocked on something, or are we just waiting out RC testing still?
[06:44] <fullermd> That knit-related thing jam had, maybe?
[07:14] <igc> bbl - out for a medical appointment
[07:30] <spiv> fullermd: I'm not the release manager, but I would like to see jam's fix in 1.4
[07:34] <fullermd> Yeah.  If it's worth a 1.3 point release, surely it should go into releases that don't yet exist   :)
[08:36]  * mtaylor is away: going to sleep... very tired
[10:08] <emgent> Unable to obtain lock lp--1227538260:///lock
[10:08] <emgent> held by emgent@bazaar.launchpad.net on host vostok [process #23990]
[10:08] <emgent> locked 13 minutes, 9 seconds ago
[10:08] <emgent> Will continue to try until 10:12:37
[10:08] <emgent> some idea to unlock ?
[10:09] <bob2> break-lock might work
[10:09] <emgent> cool.
[10:28] <fullermd> Mmm.  'viz' seems to have picked up a bug in showing Children on the Relations tab.  It's only showing 2nd (and later) children...
[12:36]  * Peng hits bzr.
[12:36] <Peng> .bzr.backup does not survive a round-trip through "bzr add" and "bzr revert" very well.
[13:16] <poolie> Peng: oh, i can imagine
[13:23]  * AfC is a bit vague why someone would want to `bzr add .bzr.backup`
[13:36] <Odd_Bloke> We should probably add it to the default ignores...
[13:39] <awilkins_> Maybe make it \.bzr.*/
[13:40] <bob2> \.o./
[13:41] <Peng> I didn't *want* to add it.. I did "bzr add", forgetting it was there.
[13:42] <Odd_Bloke> Well, there was/is a patch to change it to .backup.bzr, so that wouldn't cover that case.
[13:42] <Peng> It's "backup.bzr" now.
[13:42] <Peng> This .bzr.backup dir is just really old.
[13:42] <Odd_Bloke> So I think specifying it explicitly will ensure that it doesn't get missed in later changes.
[13:44] <Peng> AfC: I didn't *want* to add it.. I did "bzr add", forgetting it was there.
[13:44] <AfC> Peng: ah.
[13:44] <AfC> Peng: that would certainly seem a bug then - I don't think one should be able to add such a thing.
[13:59] <spiv> It might make sense to have backup.bzr on the default ignore list.
[14:02] <igc> spiv: I think that makes a lot of sense
[14:02] <igc> time for sleep - night all
[14:04] <spiv> G'night.
[14:13] <Odd_Bloke> igc: I'll make those changes and push them to LP, so as to make your merging of it easier.
[14:13] <Odd_Bloke> 'It' being the hooks stuff.
[14:31] <Peng> Hey, my ~/.bazaar/ignore file had its first birthday Monday. :D
[15:09] <jsled> I've a source file that bzr (reasonably) thought was binary.  I've removed those characters.  How to tell bzr that it's now safe to consider it a text file?
[15:11] <luks> it will do that automatically if it can't find any null bytes
[15:11] <luks> bzr doesn't really make difference between text and binary files, internally
[15:11] <bob2> I'm pretty sure bzr only considers that for display (e.g. diff) and does it at display time rather than storing it like cvs
[15:13] <jsled> after removing the bytes, `bzr diff` still calls at least one of the files binary; committing did the trick.
[15:13] <jsled> thanks.
[15:15] <gumpa> Howdy. {$bzr commit} opens $EDITOR, but issues {bzr: ERROR: empty commit message specified}
[15:15] <luks> did you save the file?
[15:16] <abentley> gumpa: You mean it does this before you have a chance to enter a message?
[15:16] <gumpa> yes, before editing
[15:16] <gumpa> saving leaves bzr_log.adslf
[15:17] <abentley> Your editor is forking probably off and giving control back before it's finished editing.
[15:17] <gumpa> Ah, so it's GVim configuration?
[15:17] <abentley> Editors can often be configured not to do this.  For example, "gvim -f" prevents this in gvim.
[15:18] <abentley> So yeah, either set EDITOR or BZR_EDITOR to "gvim -f"
[15:18] <abentley> Though personally, I prefer plain vim for that task.
[15:20] <gumpa> OK, changing $EDITOR to vim = working, I'll put that in the bzr conf
[15:20] <gumpa> thx
[15:20] <abentley> np
[15:29] <muszek> hi
[15:31] <muszek> I'm in dir /a, I have ran 'bzr init b', co I have /a/b/.bzr.  now, I'm trying to bind it to another repo, but I'm still in /a... I issue a command: 'bzr bind bzr+ssh://host/dir b' and I get an error: "bzr: ERROR: extra argument to command bind: b"
[15:32] <muszek> is there any way around it?
[15:32] <muszek> the thing is that these commands are issued from a script that's located in /a
[15:34] <muszek> n/m... I figured it out 5 seconds after I asked the question
[15:35] <abentley> bind only affects the current directory at the moment.  Some of our other commands do accept -d to specify an arbitrary directory.
[15:53] <LeoNerd> I don't suppose there's an  ununcommit command, is there? :)
[15:53] <LeoNerd> I got a bit overzealous accidentally... uncommitted too much
[16:02] <james_w> LeoNerd: pull can get you back
[16:23] <Odd_Bloke> igc: https://code.launchpad.net/~daniel-thewatkins/bzr/hooks
[16:26] <jelmer> does anybody know what the current plans are wrt 1.4?
[17:33] <cr3> is there a way for bzr to purge .pyc files when .py files are removed?
[17:36] <james_w> cr3: I don't know of one, sorry.
[17:38] <cr3> james_w: there's probably a hook mechanism I could use, that'd be neat
[17:39] <james_w> cr3: you could add a few hooks I expect, but there's not one for whenever a file is removed I don't think.
[20:59]  * Mez yawns
[20:59] <Mez> hmm, when starting a new branch, and adding lots of files  -  what annoys me most is that you have to wait twice for it to go through all the files
[20:59]  * Mez has been waiting for about 5 mins now for bzr ci to get to the editor
[21:03] <jam> Mez: "bzr add -q" "bzr commit -q"
[21:04] <jam> and, of course, "bzr commit -m 'I dont need no stinkin editor'" :)
[21:04] <Mez> yeah, but it still has to do the work
[21:04] <Mez> and I know of -m - but need multi lines
[21:05] <jam> Mez: multiple lines works fine here
[21:05] <jam> depends on your shell
[21:05] <jam> It doesn't seem to work for Win32 and .bat files
[21:05] <jam> which makes me sad
[21:05] <jam> Since I always use it everywhere else
[21:05] <jam> and don't realize it is broken until I do "bzr log" and wonder where my message went.
[21:20] <nekohayo> jelmer: does this (https://bugs.launchpad.net/bzr/+bug/177874) mean that I should now be able to merge a bzr-svn imported branch into a regular pack-0.92 branch, by any chance?
[21:22] <jelmer> nekohayo: it means you can now upgrade the pack-0.92 branch to rich-root-pack without problems
[21:23] <jelmer> nekohayo, and after that, merging shouldn't be a problem
[21:23] <nekohayo> jelmer: but what about merging? such as https://bugs.launchpad.net/bzr/+bug/202884
[21:24] <abentley> nekohayo: You will never be able to merge pack-0.92 into rich-root-pack.  pack-0.92 cannot represent the data in rich-root-pack.
[21:25] <abentley> sorry,
[21:25] <abentley> you will never be able to merge *rich-root-pack* into *pack-0.92*
[21:25] <nekohayo> means rich root pack is superior? I don't quite remember if it was supposed to be the next default, or if it was some other format
[21:26] <abentley> nekohayo: Yes, it is superior, and I hope to make it the next default format.
[21:26] <abentley> But at present, you should only use it if you need interoperability with bzr-svn data.
[21:27] <nekohayo> not stable yet?
[21:28] <abentley> It is stable, but it is incompatible with 0.92.  So if my project uses 0.92, and you use rich-root-pack, then I can't merge your changes.
[21:29] <nekohayo> when do you plan to make it the default then?
[21:31] <Odd_Bloke> nekohayo: 1.5, I think.
[21:40] <nekohayo> Odd_Bloke: o_o I see a mailing list post about bzr 1.5 dated february 2006, I'm somehow scared
[21:41] <fullermd> You probably see a post about baz 1.5   :p
[21:41] <nekohayo> baz != bazaar?
[21:41] <fullermd> Yes and No and Sorta and Once-Upon-A-Time.
[21:42] <fullermd> bazaar was baz, and is now bzr.  Discontinuity.
[21:43] <nekohayo> headache ensues?
[21:43] <fullermd> Well.  Only if you try to use baz   ;)
[21:43] <mwhudson> do not look into the light
[21:44] <nekohayo> hm. can I get bzr from bzr, and run it in place (without installing it)?
[21:46] <fullermd> For the latter, you just need to run the 'bzr' in that dir; the rest will Just Work.  The simplest way is to make a symlink somewhere in $PATH (I use ~/bin) pointing at it.
[21:48] <jam> nekohayo: and we recommend that you run "make"
[21:48] <jam> it isn't strictly required, but it allows you to use the compiled forms of a few key functions
[21:48] <jam> (we have pure python fallbacks for everything)
[21:49] <nekohayo> jam so it won't confuse itself with the systemwide-installed bzr?
[21:49] <jam> nekohayo: shouldn't
[21:49] <nekohayo> ok
[21:49] <jam> I run from ~/bin/bzr all the time
[21:49] <jam> => dev/bzr/bzr.dev/bzr
[21:49] <jam> And I still have a sys-installed one.
[21:49] <jam> Only real difference is that running from source may not find the system installed plugins.
[21:53] <nekohayo> jam it takes a helluva long time to bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev, is there a way to get just the latest?
[21:53] <nekohayo> it's a pretty huge filesize too
[21:59] <nekohayo> bzr checkout --lightweight I guess
[22:00] <jam> nekohayo: sure, I'll also put up a tarball if you give me a couple seconds
[22:00] <nekohayo> jam oh why not :)
[22:08] <jam> nekohayo: http://bazaar-vcs.org/releases/dev-snapshots/
[22:08] <jam> There is a bzr.dev-3394-tree-only.tar.bz2 there for you
[22:08] <nekohayo> thank you
[22:08] <jam> there is also a full snapshot with history (73MB, though)
[22:08] <nekohayo> and to think it's bzipped o_O
[22:10] <jam> nekohayo: well pack files are already gzipped
[22:10] <jam> bziping that doesn't help much
[22:12] <jam> unzipped is 96MB, though
[22:12] <jam> so it helped more than I though
[22:12] <jam> thought
[22:12] <jam> You know what, though, that also includes .pyc files
[22:12] <jam> as I didn't clean the tree first.
[22:27] <Mez> hmm, file operations seem to be a bit slow with lots of files in the branch
[22:28] <Mez> oh, no, just my PC running slow
[23:25] <nekohayo> urgh, I have a big question for you folks, I'm totally confused :) http://ecchi.ca:8000/bzr-question-spiced-ham.htm
[23:25] <nekohayo> I wrote it condensed into a small html page to avoid spamming the channel
[23:29] <igc> thanks Odd_Bloke
[23:37] <poolie> good morning
[23:38] <igc> morning poolie
[23:53] <vila> hi guys, can someone have a look at pqm site, it seems... slow ?
[23:53] <vila> It lloks like it always display the same tests (endind with 'tests passed') even when refreshing
[23:56] <jam> vila: what tests do you see? I see "LaunchpdaServiceTests"
[23:56] <jam> And a final "tests passed"
[23:56] <vila> some here
[23:57] <vila> same here :)
[23:57] <jam> I wonder if it is gearing up for running the ascii only versions
[23:58] <vila> I think I first saw that more than 15 minutes ago (at least), how long does it take to merge one request on average ?
[23:58] <jam> Well, there is also something funny on the PQM machine.
[23:59] <jam> Specifically I see:
[23:59] <jam> ...ServiceTests.test_environment_overrides_default   OK                 118ms
[23:59] <jam> running here on my (very new) laptop on Windows I see:
[23:59] <jam> ...lp_service.LaunchpadServiceTests.test_environment_overrides_default   OK                   3ms
[23:59] <jam> I don't know what is turning a 3ms test into a 118ms one
[23:59] <jam> but it isn't good