[00:01] ronny: put it in .bzrmeta/yourapp - make that a file that records what you need for each fileid [00:01] ronny: we don't have a scalable lookaside engine for arbitrary metadata [00:02] ronny: or put the metadata in the files - what metadata is needed for moin ? [00:02] its arbitrary key value storage per revision of an item [00:03] a revlog based backend is on my todo, they already have a normal hg one (metadata in the file tree), a anyvc one based on that is also on my todo [00:04] ronny: what keys and values? [00:04] keys are strings, values are strings/lists of strings [00:04] so you could do metadata in the file tree easily with bzr too [00:05] what query patterns are used on the metadata [00:05] moinmoin will index the metadata [00:06] lifeless: file level metadata i can keep track of would be rather nice, practically versioned xattrs [00:06] so - a full scan - how often ? [00:06] does it do partial scans? when? do they read the current file content at the same time? [00:07] it will keep a separate index, it doesnt have to read file data for metadata indexing [00:07] thats a disk index ? [00:08] yes [00:08] heh [00:08] sounds like there is duplication there, then. [00:08] well, the cache is there to make querying fast, its discardable [00:10] so the storage doesnt have to deal with metadata indexing/querying, just storage/retrival [00:14] lifeless: so its not really duplication, its just speed-up for disk space [00:19] If I upgrade a shared repository from pack-0.92 to rich-root-pack, do I need to do anything with the branches in that repository? [00:19] can you go all the way to the 2a format? [00:19] Not in this case [00:20] We are actually moving to 2a, but need to keep an older format mirror around to allow for out debian-bound sysadmins who are seemingly opposed to upgrading anything :) [00:21] But in order to be able to mirror from 2a, we need rich root [00:24] Hmm, a test conversion seems to suggest that I don't need to do anything with the branches... [00:24] In fact, bzr complains if I try to. Well, that makes the instructions easier. :) [00:28] Does bzr recognize symlinks? [00:28] what if I use symlinks pointing to directories inside and / or outside bzr WTs? [00:29] It will still version control the symlink AIUI. [00:29] AIUI? [00:29] As I Understand It [00:30] pickscrape: And what if I have a symlink to a directory within the WT? Will that directory be VCSed twice? [00:31] The symlink will be version controlled as a symlink, and nothing else. So effectively its content will be a string [00:31] pickscrape: that should be perfect.. thanks! [00:32] pickscrape: bzr st . also shows it ending with an @, so it recognizes it.. [00:32] sven_oostenbrink: yes, that makes it nicely clear :) [00:34] bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50' [00:34] reason: The file id was deleted but its children were not deleted. [00:34] Possible bzr bug? bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50' reason: The file id was deleted but its children were not deleted. [00:34] I'm trying to "easy_install bzr" on a centos5/rhel5 box, but get compile errors. Is this a known problem? [00:34] sven_oostenbrink: That doesn't look good :) [00:35] pickscrape: nah, found it already, my bad :) [00:35] fixed [00:35] sven_oostenbrink: was a directory replaced by a symlink under bzr's nose there? [00:36] pickscrape: not really... added tree, removed (with rm) a sub dir, then bzr remove --keep tree [00:37] pickscrape: ow, better even, the sub dir was replaced with that symlink yeah... man, Im messing up here! [01:14] how can i restore an accidently deleted file if i am using the centralized repository? [01:15] in svn, i was able to do an "svn update", and it would pull any missing files from the directory? [01:15] thanks... [01:15] bzr revert [01:15] bzr revert filename [01:24] thanks. === kirkland` is now known as kirkland [02:43] How can I clear a branch of everything without deleting it? [02:43] clear of changes you mean? [02:44] Yep. [02:44] bzr revert [02:44] I'm new to bzr BTW, so don't beat me up. [02:44] OK, thanks. :-) [02:44] Hmmm, that didn't remove all the commits. [02:45] <_Andrew> Hi guys, I'm checkout out a copy of our bzr repo and it's so slow. They have 400 commits and over 1.6 gig in the repo. Is there anyway to make the checkout process faster? [02:45] <_Andrew> We have** [02:46] mac9416: bzr uncommit then, but be careful [02:46] _Andrew: what protocol? [02:46] <_Andrew> from file.. it is checking out on the same machine [02:47] gutworth, how do I uncommit a _lot_ of revisions? [02:47] do you have a shared repo? [02:47] mac9416: why do you want to do that? [02:48] gutworth, the short story is that I pushed 88 revisions to an empty branch that I should have branched, merged the code into and pushed. [02:48] So now I have 88 revisions I want to get rid of so I can do it right. [02:49] gutworth, the project I work on has very loose bzr rules. Small development team. [02:49] try pulling from your own branch and giving -r [02:49] -r? [02:49] <_Andrew> shared between different users? Yes [02:49] mac9416: specify a revision [02:49] _Andrew: no, like bzr init-repo [02:49] OK, I'll try. [02:51] <_Andrew> I'm not sure [02:51] if you branch within a shared repo, revisions don't have to be copied [02:53] mac9416: you can do bzr pull --overwrite -r -88 . [02:55] <_Andrew> I'm using the bzr checkout command ? [02:57] mwhudson, that got it. Thanks. [02:57] _Andrew: checkouts can use shared repositories too. [02:57] mac9416: np [02:58] _Andrew: although perhaps you simply want "bzr checkout --lightweight"? [02:58] <_Andrew> maybe, i'm not sure on what they all mean [02:58] _Andrew: basically, if it's on the same machine, you probably don't want to actually make second copy of the 1.6 gig of history. [02:59] <_Andrew> ah yes [03:00] _Andrew: a lightweight checkout will simply point to an existing branch and repository (the repo is the bit that holds all that history), rather than copy it. [03:00] <_Andrew> ah... [03:01] <_Andrew> So it doesn't copy the .bzr data just the files [03:01] _Andrew: the other option mentioned is to make a shared repository with "bzr init-repo"... all branches (and heavyweight checkouts) created inside that repository will use the shared repository rather than keeping a standalone copy. [03:01] _Andrew: well, there will still be a .bzr directory, just less stuff in it :) [03:01] <_Andrew> I think the first option is what I need [03:02] Yeah, sounds like it, if you want to use checkouts anyway. [03:02] If you want to keep multiple branches you may want a shared repository as well at some point, but worry about that when it happens :) [03:07] <_Andrew> We have multiple branches too [03:08] <_Andrew> for example we have different tags etc [03:08] Well, there's the 'bzr tag' command so you don't need branches for that. [03:10] A common way to work is to have a shared repository made with "bzr init-repo --no-trees", so that the branches in it don't have working trees automatically. [03:11] So you have a directory that has all your branches, and all those branches share a single repository so disk isn't wasted and making new branches is really fast, etc. [03:11] And then you might have a single lightweight checkout somewhere else, and you use 'bzr switch' to switch it to different branches depending on which one you're working on. [03:12] * spiv -> lunch [03:16] hello all [03:16] bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~keryx-admins/keryx/devel/.bzr/) [03:16] is not compatible with [03:16] CHKInventoryRepository('file:///home/mac9416/aaaaaa/.bzr/repository/') [03:16] different rich-root support [03:16] Pardon the paste. Any ideas? [03:18] mac9416: you need to upgrade the remote repo apparently [03:18] mac9416: or, perhaps easier, rename it and push a new one [03:19] Hmm, how do I upgrade the remote one? [03:19] Because I'm kinda attached to the name. [03:20] mac9416: Maybe you could just rename the existing one and then push a new one with the same name. [03:20] bzr push --overwrite [03:20] (I believe) [03:21] Overwrite didn't work. Same error. [03:21] mkanat_, I'm sorry, I don't quite understand... [03:21] Perhaps bzr upgrade ? [03:25] bzr upgrade $BRANCH will work, yeah. [03:25] It'll possibly take a while, though; it (still!) needs to download & re-upload everything :( [03:25] lol, I was about to ask you if it was normal to take a while. :-) [03:25] It's a fairly small branch. [03:45] jml: just what is bzr-tools-grep [03:49] poolie: it's an emacs thingy [03:49] it basically does the bzr ls | xargs grep thing into a grep-mode buffer [04:31] poolie, what mwhudson said. the exact shell command it uses is in the email [04:32] mm [04:32] i thought it was a bzr alias or plugin [05:10] good evening === Bambi_BOFH is now known as Kamping_Kaiser [06:12] jml: I disagree on cleanups [06:12] jml: I hope I've made a convincing case in mail; please let me know if otherwise. [07:17] hi all [07:19] lifeless: I'm not sure I understand where you stand about cleanups, in one mail you said: "we should be able to reinstate that behaviour - it was removed by oversight, not intention.", as in cleanups before tearDown and in an other you said: "If you put cleanups after teardown...I argue that this is safer" [07:20] lifeless: ISTM you prefer the later but can you confirm ? [07:25] vila: the behaviour I refer to is not running teardown if setup raises an exception [07:25] that was an oversight [07:25] the order of teardowns vs cleanups is deliberate [07:27] ok. So in the end, that means banning tearDown for bzrlib (I think there are still a couple of classes that use it, in a safe way) [07:28] vila: well we can make teardown always run again [07:28] thats what I was saying [07:29] ok on that (and that's important), I mixed the two. [07:43] we could even do it in bzrlib [07:43] addCleanup(self.maybeTearDown) [07:43] def maybeTearDown(self): if not self._teardon_run: self.tearDown() [07:43] def tearDown(self): [07:43] self._teardown_run = True [07:44] [/sketch] [09:23] hello all [09:56] Hi bialix [10:13] hi jszakmeister [10:36] Bummer. The shelve-editor hasn't made it into bzr.dev yet. [10:36] s/shelve-editor/shelve-editor branch/ [10:39] Geez... updating bzr.dev pulled involved 9.5MB of transfer. :-( [10:42] I take that back... shelve-editor did make it in! === Adys_ is now known as Adys [11:19] is there a changelog for the latest version of the bzr-explorer? [11:21] The most up-to-date one is here: http://bazaar.launchpad.net/%7Ebzr-explorer-dev/bzr-explorer/trunk/annotate/head%3A/NEWS [11:22] Or here (for 0.10.0): https://launchpad.net/bzr-explorer/trunk/0.10.0 [11:22] ah yes thank you very much [11:23] You're welcome. [11:33] <_Andrew> is there anything similar to propset in bzr so that I can insert the revision number into my files? [11:38] * saedelaere waves === mrevell is now known as mrevell-lunch [12:52] when I do a "bzr info" and get back "format: unnamed", what does it mean? [12:52] what format is it? [12:52] if I do it at the shared repository level, I get 2a [12:52] but if I cd into a checkout (bound branch) and repeat it, I get "unnamed" [12:57] ahasenack: a named format is a combination of a repository format, branch format and working tree format [12:58] in your case the branch format/repository format combination used is not available as a named "bzr init --format=" option [12:58] ahasenack: if you run "bzr upgrade --2a" in the branch it should make a trivial change to the branch and "bzr info" should display 2a as the format name [12:58] ahasenack: "bzr info -v" should show you the names of the branch, repository and working tree formats [12:59] jelmer: is it possible for the root of the shared repository to have one format and the checkouts inside it have a different one? [12:59] this situation be introduced when you upgrade a repository but not the branches inside of it [12:59] it's quite possible this is what happened [12:59] I have no idea now what was upgraded and what wasn't [13:00] ahasenack: I'd recommend just running "bzr upgrade" in the repository root and the branches [13:00] that should be a no-op if the control dir is already up to date [13:00] bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format. [13:00] I guess it is [13:00] or at least the root of the shared repository is [13:01] so I can run "bzr upgrade" at the root of the shared repo [13:01] and I can also run it inside each repo from this shared repo? [13:01] it's a bit confusing [13:01] the shared bits can be upgraded separately from the rest? [13:02] yes [13:02] I agree it's a bit confusing [13:03] if I run the upgrade at the root level of the shared repository, I still have to run it inside each repository? [13:03] ahasenack: inside of each branch, yes. [13:03] ok [13:11] weird: shared repository: bzr+ssh://bazaar.launchpad.net/~landscape/landscape/trunk/ [13:11] trunk itself is a shared repo? [13:11] ops, wrong channel [13:13] ahasenack: a branch uses a repository, it is not a repo itself. As such, a repo can be shared between branches. Standalone branches use their own (private, not shared) repo [13:22] ahasenack: bzr info -v will tell you the repository branch and tree formats separately - handy when they rollup is 'unnamed' [13:23] maxb: even remotely? [13:23] You might need to prefix the URL with nosmart+ for that [13:23] aha, magic tricks [13:23] because just bzr info -v lp:~landscape/landscape/trunk doesn't tell me that === mrevell-lunch is now known as mrevell [13:47] morning all [13:47] <__monty__> Good afternoon. [13:48] * bialix waves at jam [14:15] * vila waves === CardinalXiminez_ is now known as CardinalFang [15:20] jam: inventory paths use /\'/ as \\ [15:20] grrr [15:20] jam: inventory paths use /\'/ as \\ [15:20] hey vila [15:20] argh [15:21] waiting for one more "growl" :) [15:21] jam: inventory paths use '/' as separator on *all* platforms right ? [15:21] * vila curses Apple keyboard and its \ / delete and return keys all in the same place :) [15:23] vila: id2path will always return '/' in the path [15:23] we try (too) hard to make sure we always use '/' internally [15:23] if you look at the os functions [15:23] sorry [15:23] osutils [15:24] on windows, lots of them end with ".replace('\', '/')" [15:24] vila: so yes, internally '/' is our path separator [15:24] ok so changes_from() most likely obeys that rule [15:26] I would assume so [15:26] I just discovered/realize that I can't filter changes_from output with is_ignored() (in bzr-upload context) because smart_add is the only place where *parents* are pruned when they are ignored :-/ [15:26] the main issue with supporting '\' in filenames, is just that right now, we do all we can to squash '\' to '/' [15:27] vila: so you mean if I "ignore foo/" then "foo/bar" isn't getting added? [15:27] jam: yes [15:27] if I ignore "foo/" but add "foo/bar/" then "foo/bar/baz" (i believe) will show up as unknown [15:27] testing [15:27] 'ignore foo' is enough [15:28] vila: confirmed [15:29] I was using '/' to denote that they were dirs [15:29] ok [15:29] vila: so ignoring 'foo/' just means we won't recurse by default [15:29] but if 'foo/bar' is versioned, then we will search everything underneath [15:29] hmm, the context is .bzrignore-upload [15:29] vila: I expected as such [15:30] I just wanted to mention *why* it seems to work for add [15:30] So there is no way to "force" as we do with bzr add [15:30] and that is because we don't recurse into ignored dirs [15:30] sure, makes sense [15:30] vila: you may want "foo/**/*" [15:30] which is "ignore everything under foo" [15:31] note that it *doesn't* ignore foo [15:31] yup, but that doesn't ignore foo itself :-/ [15:31] hehe [15:31] vila: so I don't know what you want to do with bzr-ignore-upload [15:31] I just wanted to note that there *is* a syntax for "ignore everything under foo" [15:32] don't upload items described in .bzrignore-upload [15:33] the main difference is that we are talking about inventory paths here, not filesystem paths, so I have to check if a filename is ignored or any of its parents (this isn't needed in bzrlib except in smart_add) [15:33] that also means I can't use osutils.dirname :-/ [15:34] vila: dirname works fine [15:34] as would "osutils.split" [15:34] splitting doesn't involve adding a '/' [15:34] err, on windows dirname() will recognize '/' ? [15:34] vila: windows already recognizes '/' as a path chare [15:34] char [15:34] it just *also* recognizes '\' [15:34] s/char/pathsep/ ? [15:35] vila: well in python pathsep == : or ; [15:35] directory separator [15:35] Windows recognizes both '\' and '/' as directory separators [15:35] grr, not pathsep, the other one :) [15:35] oooh, good news [15:36] Do we accept '\' in .bzrignore as meaning '/' ? [15:37] Or do we just don't handle them ? [15:38] vila: I think we switch them to '/', checking [15:38] globbing.normalize_pattern seems to handle the formet [15:39] vila: yep [15:39] pfew [15:39] I'm glad I asked :) [15:39] _slashes = re.compile('[\\/]') [15:39] so, '\/\/\/' will be treated as 1 '/' === sdboyer_ is now known as sdboyer === beuno is now known as beuno-lunch [16:26] beuno-lunch: lunch is for... well, may be not :) .bzrignore-upload was far more complex than I thought, see the new merge proposal [16:31] hi everyone. recently, i've been getting tons of 'No handlers could be found for logger "bzr"' messages for things like 'bzr push'. google seemed unhelpful. anybody know what's going on, or how to fix or debug the issue? i'm sure it's a python logging thing, but i'm not clear on how bzr sets that up. ftr: Bazaar (bzr) 2.0.3 on karmic [16:32] it's usually permissions, but I think you ruled that out? [16:34] james_w: i did verify that ~/.bzr.log is owned by me [16:34] james_w: as are everything in ~/.bazaar [16:35] james_w: that is the one issue google spewed up for me, but i can't find anything e.g. owned by root [16:37] are the permission bits sensible on ~/.bzr.log? [16:38] james_w: yep. 664 [16:38] if you strace it is it trying to open another log file? [16:38] james_w: hmm, good idea. let me try [16:39] strace -e open /usr/bin/bzr info 2>&1 | grep log [16:40] and this is usual bzr operations with a plain unpatched bzr? [16:40] does it still happen with --no-plugins? [16:41] barry: also, if you could do a run where you see it, and stop with ^\ to get into the debugger [16:41] c = self [16:41] while c: [16:41] then we can poke around with what is going on [16:41] that's rather odd code in a method isn't it? [16:41] james_w: that does look a little odd [16:41] james_w: i only see it trying to open ~/.bzr.log; this is stock /usr/bin/bzr; still happens with --no-plugins [16:42] barry: and it succeeds in opening ~/.bzr.log? [16:42] james_w: it does [16:42] james_w: and writing to it [16:43] jam: let me see if i can catch it [16:43] barry: if i understand the problem correctly, it should happen any time you try to connect to an sftp location, or ssh location using paramiko [16:43] barry: this is using bzr 2.0.3 ? [16:44] jam it is and this is a bzr+ssh url [16:44] do you have BZR_SSH set? [16:45] (env var) [16:45] jam: no [16:45] del bzr_logger.handlers[:] [16:45] doesn't that delete a copy of the list, and so is basically a no-op? [16:45] k, well if it is 2.0.3, I'm pretty sure poolie's "stop using the logging" module isn't present [16:45] james_w: no, it empties the list [16:45] james_w: no, that is python syntax for clear the list [16:45] ok [16:46] del "operates" on names, not references [16:46] bad syntax IMO, but that is the syntax [16:46] there's effectively a whole bunch of special forms of del [16:46] same as 'del d[key]' [16:47] lists should really have a .clear() method like dicts, but that's a digression :) [16:47] "del foo" deletes a local name, "del foo.bar" invokes __delattr__, "del foo[bar]" invokes __delitem__ [16:47] idnar: so is it the parser that turns it into the special construct? [16:48] jam: so it sounds like this is a known issue in 2.0.3. if so, i will happily ignore it :) [16:48] barry: I don't think it is [16:48] It sounds like something strange happening [16:48] you could also just try [16:48] from bzrlib import logging [16:48] sorry [16:48] jam: ok! i'd file a bug, but it seems like i don't have enough information yet :/ [16:48] from bzrlib import trace; trace.enable_default_logging() [16:48] jam: I'm not sure of the exact mechanics, but it ultimately compiles to different bytecode ops [16:48] and see if that has a problem [16:48] idnar: *glee* [16:49] barry: and what were you using before you ran into this problem? 2.0.2 ? [16:49] there's DELETE_GLOBAL and DELETE_FAST for names, DELETE_SUSCR for del foo[bar], and DELETE_ATTR for del foo.bar [16:49] (I'm trying to understand how it "just started" ) [16:50] jam: python -c "from bzrlib import trace; trace.enable_default_logging()" produces no such message [16:50] barry: Now I would expect: "from bzrlib import trace; trace.mutter('foo')" to generate that [16:50] and [16:50] "from bzrlib import trace; trace.enable_default_logging(); trace.mutter('bar')" not to [16:51] jam: well, that's the thing, i'm not entirely sure when it started. "recently" is the best i can say. the only thing that comes to mind is that i started using etckeeper, but i would have thought --no-plugins would eliminate that (and i'm not doing pushes in /etc) [16:51] sorry 'trace.note()' but I can't reproduce that here [16:51] barry: and once again I'm proven wrong [16:52] it takes "trace.warning" to provoke the handlers issue [16:52] jam: [16:52] % python -c "from bzrlib import trace; trace.enable_default_logging(); trace.warning('bar')" [16:52] bar [16:52] no logger warning [16:52] barry: and without the "enable_default_logging" [16:53] jam: bingo! [16:53] barry: right [16:53] warning and no "bar" [16:53] so you have to try to log something that looks severe enough, but not have a handler enabled === beuno-lunch is now known as beuno [16:53] jam: why, or maybe who, is not installing the handler? [16:54] barry: we install the handler as part of main, IIRC [16:54] checking [16:54] the difference between note and warning is that warning will go through the added stderr handler [16:54] barry: it looks like it is in the "bzr" main script [16:54] before calling main [16:55] barry: care to put an "import pdb; pdb.set_trace()" in 'bzr' and step through it to see when the warning hits? [16:55] jszakmeister: ping [16:55] vila, ah, that's quite a change [16:55] jam: yep, that does seem like the next step. [16:55] barry: looking at the 'bzr' code, it looks like we would have to be emitting a warning during import [16:56] beuno: yeah, not that simple :) [16:56] as plugins aren't even loaded yet [16:56] barry: the common case is when "enable_default_logging()" itself fails [16:56] specifically: except IOError, e: [16:56] warning("failed to open trace file: %s" % (e)) [16:56] which because it cannot open the trace file has not yet set up logging, and ends up getting suppressed [16:57] we should probably just change that to "sys.stderr.write()" [16:57] jelmer: isn't that log bug caused by ghosts? [16:57] barry: however, you claimed that ~/.bzr.log isn't a problem [16:57] jelmer: oh no, ignore me, sorry [16:57] jam: right. does not seem to be! [16:57] barry: you know what, check ~/.bzr.log.old [16:58] I wonder if your log is full, and it is failing to get rid of the old one [16:58] jam: i have no ~/.bzr.log.old [16:58] barry: anyway, stepping through with pdb is the best way to isolate it [16:58] barry: what size is ~/.bzr.log ? [16:58] jam: 782715 [16:58] hmm.. we roll at 4MB, so no issue there [16:59] back to pdb :) [16:59] :) trying... [17:06] jam: so far, i've narrowed it down to push.py:83 in bzr.dev [17:06] dir_to = bzrdir.BzrDir.open_from_transport(to_transport) [17:08] barry: so this seems to be happening a long time after bzrlib.trace.enable_default_logging() has been called [17:08] yep [17:08] barry: does that fit what you are seeing [17:08] very strange [17:08] remote.py:124 [17:08] barry: you could try putting something into 'trace.warning' but I have the feeling something is going directly to the logging module [17:10] jam: happens before we hit the first call to warning() [17:10] barry: I think error would also trigger it [17:10] but 'note' and 'mutter' seem to be defaulted to silence [17:10] maybe there is an 'info' call? [17:10] happens before the first call to error too [17:11] and before the first call to info() [17:11] in fact, before the first call to anything in trace.py [17:11] barry: btw, does *python* guarantee that "open().name" works? [17:12] I'm trying to define an api, and I want to know whether I have to pass a path as well as a file object, or if I can assume the file object has a .name attribute [17:13] jam: well, the stdlib says "may not be present on all file-like objects" but i belive for actual file objects, yes it does guarantee that [17:14] barry: sure, StringIO may not have it, but that doesn't have an fs path either :) [17:14] right :) [17:15] jam: narrowed down to client.py:87 [17:16] jam: where method='BzrDir.open_2.1' [17:16] barry: sure, I'm guessing that send_request is causing an actual connection to be spawned [17:17] oh, and if you are sitting there [17:17] we can try something else [17:17] namely, check the transport [17:17] and its connection [17:17] and see whether it is using paramiko itself [17:17] etc [17:17] would that be self? [17:18] or rather, i'm not sure where transport and connection are [17:19] protocol.py:1303 [17:19] or maybe 1302 [17:23] jam: well, here's an interesting thing. in ssh.py:367 it calls subprocess.Popen() where argv[0] == 'ssh'. it is in this call that the No handlers warning gets emitted [17:23] jam: is it possible this is happening on the server? [17:23] barry: hmm... that at least looks like the server is generating an error [17:23] barry: it is definitely possible [17:23] * barry checks the server [17:23] and the error would get propogated over ssh's stderr output [17:23] without bzr doing anything [17:23] so if on the *server* you have a problem with ~/.bzr.log [17:23] this would be much less suprising [17:24] jam: bing [17:24] er, bingo :) [17:25] old mac's dog? [17:26] jam: :) ~/.bzr.log on the server was owned by root. fixing that made the problem go away. this explains everything, since this is a new-ish server and it explains why all the clients suddenly saw the same thing [17:26]