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