[01:10] <glyph> Hiya. We've got a buildbot which is using bzr, while our main repository is still SVN.  The buildbot wants to build svn revisions.  svn:revno almost does what we want, except it demands a level of precision we can't necessarily provide:
[01:10] <glyph> To wit, when we have a revision number that is in a branch, but we try to check it out on trunk, we don't get the "highest without going over" behavior that "svn checkout" would produce.
[01:11] <glyph> Is there a way to get that behavior without lots of hacking of 'bzr log' and its output?
[01:14] <lifeless> possibly
[01:14] <lifeless> uhm
[01:14] <lifeless> before:svn:xxx
[01:14] <lifeless> or after:svn:xxx
[01:15] <lifeless> or you could write a plugin for svn-approx:xxxx
[01:15] <lifeless> which would do whatever you need
[01:15] <lifeless> revision resolving plugins are pretty simple
[01:16] <glyph> lifeless: interesting
[01:17] <glyph> lifeless: that doesn't seem to work though.
[01:17] <glyph> bzr: ERROR: Unsupported protocol for url "after:svn:34810"
[01:20] <lifeless> after might be science fiction
[01:20] <lifeless> I suspect you need a small resolver
[01:21] <lifeless> bzr help revisionspec will give you the current ones
[01:21] <lifeless> you can look at e.g. bzr-svn to see how svn: is implemented and registered
[01:23] <glyph> lifeless: OK.  Probably don't need it, but that's good to keep in mind.  I did write a bunch of shortcut plugins for my own personal use :)
[01:23] <glyph> no revision plugins though.
[01:28] <spiv> revspec plugins are pretty straightforward.
[01:28] <lifeless> glyph: I suspect a plugin is what you need, that or a patch to the svn revspec to be fuzzy
[04:11] <tomprince> bzr: ERROR: Requested revision: u'svn:35497' does not exist in branch: BzrBranch7('http://svn.twistedmatrix.com/bzr/Twisted/trunk/')
[04:12] <tomprince> ^--- does this indicate an out-of-date version bzr/bzr-svn?
=== _thumper_ is now known as thumper
[04:28] <spiv> tomprince: is the bzr-svn plugin loaded?  (does it appear in 'bzr plugins' ?)|
[04:28] <spiv> Or possibly it means that bzr mirror of the svn trunk is out of date?
[04:44] <tomprince> I don't have access to the host. It could be that the bzr-svn plugin is loaded.
[04:45] <tomprince> http://buildbot.twistedmatrix.com/builders/rhel6-32bit-py2.6/builds/984/steps/bzr/logs/stdio
[04:45] <tomprince> spiv: ^--- is the output I get.
[04:47] <tomprince> I'm trying to diagnose the problem remotely, so I can provide instructions to the person who has access to the machine.
[04:57] <spiv> I guess ideally the 'bzr' step of that buildslave config would capture the .bzr.log and put it somewhere visible.
[04:57] <spiv> Or perhaps run bzr with -Derror or something
[05:01] <spiv> Well, 'bzr log -r-1 -v --long --show-ids http://svn.twistedmatrix.com/bzr/Twisted/trunk/' shows its currently at svn's r35499
[05:02] <spiv> So that error does suggest that there's something wrong with bzr-svn on that slave.
[08:07] <mgz> morning
[08:51] <jelmer> pom
[08:55] <jelmer> tomprince: hi
[08:55] <jelmer> tomprince: did that revision touch that particular branch?
[11:10] <jml> *awesome*
[11:10] <jml> $ bzr di
[11:10] <jml> === modified file 'sourcedeps.conf'
[11:10] <jml> bzr: ERROR: Could not understand response from smart server: ['x\x9c\xa5\x92\xcb\x0e\x820\x10E\xd7\xf2\x15\xee\r\xad\xa0\x10\x1f\xf1cJ[\xa1\x81>\x9c\xb6$\xb2\xf0\xdb\x85\x80Q0\x01\x13\x17\x93Lf\xe6\xde\x93\xde\x14a!\x8d\x06\x17Z']
[11:10] <mgz> hm... new in the last few days I take it?
[11:11] <jml> mgz: new today for me
[11:11] <jml> lightweight checkout
[11:11] <mgz> we upgraded launchpad to bzr 2.5.1 which has some new fancy for doing some operations over the smart server that weren't before
[11:11] <mgz> so, please file a bug with as much info as possible.
[11:12] <jml> ok.
[11:13] <mgz> obvious work around is have a local trunk branch that you branch from, so diffs from lwc use that
[11:13] <jml> yeah, I'm doing that right now
[11:13] <mgz> thanks jml.
[11:13] <jml> huh, apparently a lock has been taken
[11:13] <mgz> ...you might need to manuall break it
[11:13] <mgz> also worth putting in the bug report
[11:14] <mgz> ah... launchpad might be unhappy right now?
[11:18] <jml> mgz: https://bugs.launchpad.net/bzr/+bug/1046265
[11:18] <ubot5> Ubuntu bug 1046265 in Bazaar ""Could not understand response from smart server" when diffing lightweight checkout of LP branch" [Undecided,New]
[11:18] <mgz> is it repoducable, I neglected to ask?
[11:19] <jml> mgz: yes, although I haven't tried from a fresh light-weight checkout, only one that already existed.
[11:45] <jam> mgz, jelmer: any success with the python-defaults stuff?
[11:47] <jam> jml: what were you using a lightweight checkout for that you were running diff? (the only specific common one I know of is the download-cache, but diff is pretty useless for tarballs)
[11:48] <jml> jam: a branch that contains only a config-manager configuration file, sourcedeps.conf
[11:48] <jelmer> jml: can you file a bug about this issue?
[11:49] <jml> jelmer: is https://bugs.launchpad.net/bzr/+bug/1046265 somehow insufficient?
[11:49] <ubot5> Ubuntu bug 1046265 in Bazaar ""Could not understand response from smart server" when diffing lightweight checkout of LP branch" [High,Confirmed]
[11:49] <jam> jelmer: he did file #1046265 was there another one?
[11:49] <jelmer> jml: worked on landing use-bzr-policy-open earlier, and am going to upload a new python-defaults soon
[11:49] <jelmer> jml: No, that's great - thanks
[11:49] <jml> jelmer: np.
[11:49] <jelmer> I didn't see that
[11:50] <jam> jelmer: use-bzr-policy-open?
[11:50] <jam> an lp branch
[11:50] <jelmer> jam: yep, to get launchpad to use the bzr code for safely opening branches
[12:08] <jml> see also $ bzr ci
[12:08] <jml> Committing to: bzr+ssh://bazaar.launchpad.net/~canonical-ca-hackers/ca-configs/txpkgme-configmanager/
[12:08] <jml> modified sourcedeps.conf
[12:08] <jml> bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://jml@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
[12:08] <jml> Traceback (most recent call last):
[12:08] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 930, in exception_to_return_code
[12:08] <jml>     return the_callable(*args, **kwargs)
[12:08] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 1141, in run_bzr
[12:08] <jml>     ret = run(*run_argv)
[12:08] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 673, in run_argv_aliases
[12:08] <jml>     return self.run(**all_cmd_args)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commands.py", line 697, in run
[12:09] <jml>     return self._operation.run_simple(*args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 136, in run_simple
[12:09] <jml>     self.cleanups, self.func, *args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
[12:09] <jml>     result = func(*args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/builtins.py", line 3688, in run
[12:09] <jml>     lossy=lossy)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 218, in write_locked
[12:09] <jml>     result = unbound(self, *args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/workingtree_4.py", line 218, in commit
[12:09] <jml>     result = WorkingTree.commit(self, message, revprops, *args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/decorators.py", line 218, in write_locked
[12:09] <jml>     result = unbound(self, *args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/mutabletree.py", line 211, in commit
[12:09] <jml>     *args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 290, in commit
[12:09] <jml>     lossy=lossy)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 132, in run
[12:09] <jml>     self.cleanups, self.func, self, *args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
[12:09] <jml>     result = func(*args, **kwargs)
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/commit.py", line 452, in _commit
[12:09] <jml>     self.builder.abort()
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/vf_repository.py", line 217, in abort
[12:09] <jml>     self.repository.abort_write_group()
[12:09] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/remote.py", line 1212, in abort_write_group
[12:09] <jml>     suppress_errors=suppress_errors)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repository.py", line 282, in abort_write_group
[12:10] <jml>     self._abort_write_group()
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repofmt/pack_repo.py", line 1708, in _abort_write_group
[12:10] <jml>     self._pack_collection._abort_write_group()
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repofmt/pack_repo.py", line 1565, in _abort_write_group
[12:10] <jml>     operation.run_simple()
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 136, in run_simple
[12:10] <jml>     self.cleanups, self.func, *args, **kwargs)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/cleanup.py", line 166, in _do_with_cleanups
[12:10] <jml>     result = func(*args, **kwargs)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/repofmt/pack_repo.py", line 436, in abort
[12:10] <jml>     self.upload_transport.delete(self.random_name)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/transport/remote.py", line 313, in delete
[12:10] <jml>     resp = self._call2('delete', self._remote_path(relpath))
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/transport/remote.py", line 181, in _call2
[12:10] <jml>     return self._client.call(method, *args)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 59, in call
[12:10] <jml>     result, protocol = self.call_expecting_body(method, *args)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 72, in call_expecting_body
[12:10] <jml>     method, args, expect_response_body=True)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 55, in _call_and_read_response
[12:10] <jml>     return request.call_and_read_response()
[12:10] <jam> jml: pastebin is your friend :)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 157, in call_and_read_response
[12:10] <jml>     return self._call(protocol_version)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 189, in _call
[12:10] <jml>     response_handler = self._send(protocol_version)
[12:10] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 265, in _send
[12:10] <jml>     encoder, response_handler = self._construct_protocol(protocol_version)
[12:11] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/client.py", line 241, in _construct_protocol
[12:11] <jml>     request = self.client._medium.get_request()
[12:11] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/medium.py", line 884, in get_request
[12:11] <jml>     return SmartClientStreamMediumRequest(self)
[12:11] <jam> also, at least with a trivial branch here, I don't see the failure when creating a new lightweight checkout of a single-file single-commit branch and modifying it and committing.
[12:11] <jml>   File "/usr/lib/python2.7/dist-packages/bzrlib/smart/medium.py", line 1167, in __init__
[12:11] <jml>     raise errors.TooManyConcurrentRequests(self._medium)
[12:11] <jml> TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(bzr+ssh://jml@bazaar.launchpad.net/)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.
[12:11] <jml> bzr 2.6.0dev3 on python 2.7.3 (Linux-3.5.0-10-generic-x86_64-with-
[12:11] <jml>     Ubuntu-12.10-quantal)
[12:11] <jml> arguments: ['/usr/bin/bzr', 'ci']
[12:11] <jml> plugins: bash_completion[2.6.0dev3], branchdashboard[unknown],
[12:11] <jml>     bzrtools[2.5.0], changelog_merge[2.6.0dev3], damage[unknown],
[12:11] <jml>     difftodo[unknown], grep[0.5.0dev], launchpad[2.6.0dev3],
[12:11] <jml>     netrc_credential_store[2.6.0dev3], news_merge[2.6.0dev3],
[12:11] <jam> jml: so if this is a public thing, can you tar up your local checkout, and put it somewhere for us to test?
[12:11] <jml>     po_merge[2.6.0dev3], pqm[1.4.0dev], stats[0.2.0dev], svn[1.2.3dev],
[12:11] <jml>     weave_fmt[2.6.0dev3]
[12:11] <jml> encoding: 'utf-8', fsenc: 'UTF-8', lang: 'en_GB.UTF-8'
[12:11] <jml> *** Bazaar has encountered an internal error.  This probably indicates a
[12:11] <jml>     bug in Bazaar.  You can help us fix it by filing a bug report at
[12:11] <jml>         https://bugs.launchpad.net/bzr/+filebug
[12:11] <jml>     including this traceback and a description of the problem.
[12:11] <jml> oops
[12:11] <jml> sorry.
[12:11] <jml> you know that thing where hitting Ctrl-C doesn't always copy because something in Ubuntu is slower than I am? that.
[12:11] <jml> I had meant https://bugs.launchpad.net/bzr/+bug/1046284
[12:11] <ubot5> Ubuntu bug 1046284 in Bazaar "TooManyConcurrentRequests when committing to lightweight checkout" [Undecided,New]
[12:11] <jml> no it's not
[12:12] <jml> jam: this is a different branch (I think)
[12:12] <jml> jam: chinstrap:~jml/txpkgme-configmanager.tar.gz
[12:13] <jam> jml: and this is using Q with the packaged bzr? or bzr.dev? or ?
[12:14] <jml> jam: packaged Q. (should I have included more information in the bug report?)
[12:15] <jam> jml: I think it has enough info there, but sometimes it is easier to just ask
[12:15] <jml> :)
[12:16] <jam> jml: bzr status says: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~canonical-ca-hackers/ca-configs/txpkgme-configmanager/".
[12:16] <jml> jam: oh. well. it is a branch.
[12:16] <jam> jml: https://code.launchpad.net/~canonical-ca-hackers/ca-configs
[12:17] <jam> are you sure it isn't private?
[12:17] <jml> jam: oh yeah, it's private.
[12:17] <jam> so... I can't see it then :)
[12:17] <jml> jam: but not for any good reason that I know of
[12:17] <jam> jml: you are welcome to make it public, or add me for analysis purposes.
[12:17] <jml> jam: ah, right. you still work for Canonical, right? :P
[12:17] <jam> (and then kick me out later so I don't get bug spam)
[12:17] <jam> jml: I got paid last month, so I'm pretty sure I do
[12:21] <jml> jam: I've subscribed you to txpkgme-configmanager. Let me know if you need more access.
[12:22] <jam> jml: I can see it, and I can confirm that 'bzr diff' gives me a failure
[12:25] <jml> cool.
[12:42] <jam> jml: ok, I think I've figured out the bug
[12:42] <jam> I'm not sure why the ordering is this way
[12:43] <jam> but essentially, the _iter_files_bytes code yields a 'call this function to get the content of the file'
[12:43] <jam> however, the outer code is never calling that function.
[12:43] <jam> which means the bytes of the file are still in the stream
[12:43] <jam> so the next iteration goes through and says "is there another record here" and gets the file content instead of the tail of the stream.
[12:49] <jam> jml, jelmer: I see why now, should be a simple-ish fix
[12:50] <jelmer> jam: Thanks for debugging that
[12:50] <jelmer> jam: Are you submitting a fix?
[12:50] <jam> jelmer: yeah, the specific issue is that WT4 is doing list(iter_files_bytes())[0]
[12:50] <jam> however, that consumes the iterator
[12:50] <jam> *before* it consumes the content.
[12:50] <jelmer> ah
[12:51] <jam> so we just have to turn it into a for loop, etc.
[12:51] <jam> and then think about if we have a test hole.
[12:52] <jam> iter_files_bytes wasn't being used according to its spec, so one implementation did it differently (remoterepo vs local repo)
[12:52] <jam> but it wasn't detected because local repo caches the contents and returns a trivial function
[12:54] <jam> jelmer: interestingly, it looks like i'm the one to blame.
[12:54] <jam> back in rev 4204
[12:55] <mgz> well, that's nice.
[12:55] <jelmer> jam: to be fair, we never had that behaviour until recently
[12:55] <jam> jelmer,mgz: yeah it worked because we didn't actually implement iter_files_bytes as an RPC
[12:56] <jam> I wrote get_file_text back in bzr-1.14.. wow.
[12:56] <mgz> but iters that happen to always be listiter then usage breaking when that changes kind of thing isn't uncommon
[12:56] <jam> mgz: yeah, the issue is that you have to consume the callable returned as you iterate
[12:56] <jam> which I think has bit us once before, but it is pretty uncommon.
[12:56] <mgz> ...I think those words would make sense if I'd put them together in the right order
[13:00] <jam> mgz: well, I know the code and the problem, so it made enough sense to me :)
[13:09] <jam> jelmer, mgz: it has been a while since I dug into the hard bits. How would you set up a test for a lightweight checkout of a remote repository?
[13:10] <jelmer> jam: it depends a bit; for what you're hitting now I guess a blackbox test might be most appropriate?
[13:10] <jam> jelmer: I'd like to do a per-wt test sort of thing.
[13:11] <jelmer> jam: There are no tests verifying wt against a specific remote branch I think
[13:11] <jam> jelmer: yeah, which I think is part of the testing hole I mentioned earlier.
[13:11] <jelmer> jam: perhaps just add a test in bzrlib/tests/per_workingtree/ that sets up some remote branch and gets the wt to use that, if they are compatible?
[13:12] <mgz> jam: probably subclass TestCaseWithTransport then parametrise against classes in bt.test_server
[13:14] <mgz> ReadonlySmartTCPServer_for_testing should do, can then operate on branch locally the check it out, and make some tree changes, and diff
[13:15] <jam> mgz: well, I only need to call 'wt.get_file_text()' with a backing of a remote repo, so 'dif' isn't necessary
[13:15] <jam> (it is also why commit fails, etc.)
[13:15] <mgz> doesn't seem like per_workingtree has any remote tests
[13:15] <jam> well, I'm guessing, I didn't try to commit to a branch that isn't mine :)
[13:15] <jam> right
[13:32] <idnar> so there's `bzr deleted` and `bzr renames`; is there anything like `bzr modified`?
[13:33] <idnar> I'm looking for something nicer than bzr status -S | horrible-shell-hacking-here
[13:34] <mgz> idnar: what would be calling that?
[13:35] <idnar> I want to open all modified (and added, for that matter) files in my editor; so something like gvim -p $(bzr blahblah) would be my usage
[13:35] <idnar> it's not too important, I was just wondering if I missed something easy
[13:46] <mgz> hm, so writing shell is probably no worse than using the python bzrlib api or a plugin
[13:47] <fullermd> ls is more the interface intended for that.
[13:49] <mgz> odd, ls seems to be showing me ignored files by default
[13:50] <mgz> and lots of files that are not in fact modified...
[13:50] <fullermd> Hm, I thought ls had --modified and --deleted and such. But the help doesn't list them.
[13:51] <mgz> idnar: so, that's probably what you want, you might just need to submit some patches to fix it first :)
[14:42] <micahg> bzr: ERROR: zlib.error: Error -3 while decompressing: incorrect header check   trying to branch a local git repo to bzr
[15:12] <hariom> What are pros and cons of creating bzr repo in non root user space
[15:14] <mgz> hariom: I don't know exactly what you mean, but I can't think of any reason you'd want to do it.
[15:15] <mgz> micahg: is that a bug report or an observation?
[15:15] <micahg> mgz: it's an observation, I'm happy to file a bug report if appropriate :)
[15:15] <micahg> google was not forthcoming with a matching bug report
[15:16] <mgz> without traceback context (see .bzr.log) it's hard to suggest anything
[15:17] <micahg> mgz: http://paste.ubuntu.com/1187398/
[15:18] <mgz> generally errors from zlib mean a data file has been corrupted, but branching from git (which doesn't use the same mechanisms) might mean it's a dulwich bug or something
[15:21]  * micahg wishes he knew the equivalent of bzr check for git
[15:22] <mgz> right, was going to suggest that, but also don't know it
[15:24] <mgz> could set BZR_PDB=1, repeat the operation, step up the stack trace a bit and see if the packfile looks sane
[15:35] <mgz> micahg: either way, a bug report against dulwich would not hurt
[15:37] <gmarkall> would the bzr check equivalent be git fsck, maybe with --full and/or --strict?
[15:39] <micahg> gmarkall: ooh, thanks
=== abentley is now known as abentley-lunch
[16:31] <micahg> mgz: consistency check finished, checkout still failed, I guess a dulwich bug it is then
=== abentley-lunch is now known as abentley
[18:24] <mgz> oh, pants
[18:24] <mgz> how do I cancel a pqm run...
[18:27] <lifeless> sudo make me a sandwhich
[18:27] <mgz> I fear that won't work.
[18:27] <lifeless> sandwich then
[18:27] <mgz> and it's past the merge step to renaming the branch from under it is no good.
[18:28] <mgz> ...I don't have rights to uncommit from bzr.dev so can't fixup afterwards either
[18:29] <lifeless> land the reverse patch.
[18:29] <lifeless> uncommit on public branches is evil anyhow.
[18:29] <mgz> how much will webops hate me if I ask them to kill the process on whatever machine bzr's pqm runs on these days?
[18:29] <lifeless> well, thats what I meant by sudo :P
[18:29] <mgz> the merge will work, it's just targetted at the wrong branch, so will confuse the history
[18:29] <lifeless> its a fairly routine request - is it mid test run ?
[18:30] <mgz> yup,
[18:32] <mgz> thanks lifeless. I really must let launchpad load the diff before sending these routine things to land.
=== deryck is now known as deryck[afk]
[18:57] <chinoto> http://doc.bazaar.canonical.com/beta/en/admin-guide/simple-setups.html#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories
[18:58] <chinoto> so my coworker decided to use that link to restrict access to our dev server so... "outsource workers"? could work on a project with us, but I can't even do a simple "bzr whoami"
[19:09] <chinoto> shnarf
[19:11] <mgz> chinoto: why would you want to run `bzr whoami` on the dev server?
[19:12] <mgz> and what exactly is the problem you're having?
[19:16] <chinoto> well I wanted to run "bzr update", but it didn't work so I decided to try a simpler command and saw whoami
[19:20] <chinoto> we have lines like this in '.ssh/authorized_keys'
[19:20] <chinoto> command="bzr serve --inet --allow-writes --directory=/home/bzr/repo",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAA...= XYZ
[19:20] <chinoto> and I tried to do 'ssh bzr@dev.ffusa.net "bzr whoami"', but it just blinked at me...
[19:29] <maxb> chinoto: you misunderstand how that ssh authorized keys stuff works - it means you cannot run commands on the server, so of course ssh host command does not work
[19:33] <chinoto> perhaps it isn't misunderstanding, but not understanding in the first place :3
[19:42] <chinoto> so I'm guessing this means I can only interact with the server through local bzr commands (eg 'bzr log --line :parent'). in order to update the server's working tree I would have to ssh in as a different user and do 'sudo -u bzr bzr update'?
[19:43] <lifeless> if you have a working tree
[19:43] <lifeless> servers generally don't
[19:43] <chinoto> well we do
[19:43] <lifeless> you may want bzr-upload for publishing a website, for instance.
=== deryck[afk] is now known as deryck
=== mwhudson_ is now known as mwhudson