[00:01] <lokkju> jelmer, paths
[00:02] <lokkju> we're trying to do a branch operation from a remote repo, and it's telling us one of the files exceeds that limit
[00:04] <jelmer> lokkju: yes, that might very well be possible
[00:06] <lokkju> so...  any way around it?  Window XP and newer's limit is actually 65K, but I've seen this same issue with svn - it is something about the libraries that are being linked to or something
[00:07] <lokkju> ack, 32K
[08:38] <AfC> How can you restrict bzr+ssh to a specified directory path rather than bzr+ssh+//user@hostname/path implyng / ?
[08:39] <AfC> ie, something like http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/ but serve side. Is that possible with some sshd_config magic, maybe?
[08:41] <fullermd> authorized_keys entries are server-side...
[08:42] <AfC> fullermd: oh,
[08:42] <AfC> duh
[08:42] <AfC> right
[08:42] <AfC> Ok, so maybe a different question
[08:43]  * fullermd gets you an extra coffee mug   8-}
[08:43] <AfC> That's fine for users who are *only* doing bzr+ssh when they connect,
[08:43] <AfC> but what about users who also have normal accounts there?
[08:43] <AfC> (ie, me as opposed to everyone else)
[08:44] <AfC> fullermd: ie, I have bzr://research.operationaldynamics.com/bzr/java-gnome/mainline/ and http://research.operationaldynamics.com/bzr/java-gnome/mainline/ for public serving, but it sure would be nice
[08:44] <AfC> fullermd: to have bzr+ssh://research.operationaldynamics.com/bzr/java-gnome/mainline/ for pushing, rather than the current
[08:44] <fullermd> Clean and/or pure-bzr solutions?  I don't know of any.  I can dream up a few somewhat hackish things.
[08:45] <fullermd> Of course, you can use authorized_keys and use different keys, which isn't without drawbacks.
[08:45] <AfC> fullermd: too-muc-info bzr+ssh://epsilon.dal.operationaldynamics.com/export/web/com/operationaldynamics/research/bzr/java-gnome/mainline/
[08:45] <fullermd> (but can work, depending)
[08:45] <AfC> I mean, obviously I could put a symlink in / as /bzr -> path, but that seems so wrong
[08:46] <AfC> I'm wondering if sshd gets any information about the hostname that was requested
[08:46] <fullermd> Marginally less wrong would be a symlink at ~/bzr and bzr+ssh://blah/~/bzr/ of course.
[08:46] <AfC> (outbound, ssh_config keys on hostname target
[08:46] <fullermd> I don't think so.
[08:46] <AfC> what about receiving side in [well, not sshd_config, but something?)
[08:47] <AfC> fullermd: actually, yeah, the home directories might be a better option, in the final analysis.
[08:47] <AfC> hm
[08:47] <AfC> right now we have a shared repo, but...
[08:48] <fullermd> Well, I didn't mean _moving_ stuff under homedirs, just adding the symlink for shorter typing on access.
[08:49] <AfC> oh
[08:49] <AfC> hm
[08:49] <AfC> {shrug}
[08:49] <AfC> yeah,
[08:49] <AfC> that's not bad
[08:50] <AfC> fullermd: good thinking
[08:50] <fullermd> One variant of the uglyhack solution would be to tweak shell rc files so that noninteractive logins get a 'bzr' that's a wrapper script setting --directory.
[08:50] <AfC> yeah, I'm just pondering along those lines
[08:50] <AfC> maybe
[08:51] <AfC> well, maybe a different sshd instance on a different port
[08:51] <AfC> or some kind of port forwarding, or...
[08:51] <AfC> hm
[08:51] <fullermd> Another is to hack up bzr one way or another (direct hackery, maybe something can be done in a plugin, etc) to fiddle with the command it invokes when you bzr+ssh.
[08:51] <fullermd> Different port wouldn't gain you anything over using a separate key with the authorized_keys fiddling.
[08:51] <AfC> yeah
[08:52] <AfC> damn
[08:52] <AfC> this seems like it should be simple
[08:52] <AfC> well
[08:53] <AfC> well. If the server is ONLY for bzr, then hacking the authorized_keys (or whatever) would do it I suppose. My problem is that this server does a few other things.
[08:53] <fullermd> Or you could pretend you're Launchpad, and just build your whole thing on top of a fictitious pseudofs  :p
[08:53] <fullermd> You can have multiple keys.  Just have a special one for bzr stuff.
[08:54] <fullermd> You can use your local .ssh/config and a separate hostname to auto-choose it for "bzr.myhost" instead of "myhost" (or whatever other trickery you may want)
[08:54] <AfC> yeah, but then I'd have to make `bzr push bzr+ssh:host` use a different one than `ssh host` does... erum oh
[08:54] <AfC> well,
[08:54] <AfC> yeah
[08:54] <AfC> duh
[08:54] <AfC> that could work
[08:54] <AfC> client side, ssh_config
[08:54] <AfC> specify a different IdentityFile
[08:54] <fullermd> Well, if you wanted to go systemwide...
[08:55] <AfC> yeah, I meant .ssh/config
[08:55] <AfC> nice
[08:55] <fullermd> One downside is that you end up not taking such advantage of connection sharing there, assuming you're doing so in the first place.
[08:55] <AfC> sort of a bother to have to have another key, but hey, yes, I'll live
[08:55] <fullermd> Of course, given the sorry state of manglement for connection sharing...
[08:55] <AfC> yeah
[08:56] <AfC> I gave up on connection sharing when I realized (duh) that a root@ and user@ wouldn't share the connection.
[08:56]  * fullermd is amazed and how that hasn't improved in $YEARS.
[08:56] <fullermd> Sure, but who ssh's as root?   :p
[08:56] <AfC> (I also noticed that even user@ and user@ has a lot of ugly race conditions if you start doing any port forwarding
[08:56] <AfC> fullermd: not me, of course.
[08:57] <AfC> fullermd: [our security team had a hard think about that, and decided that inhibiting sysadmins from being root was stupid]
[08:57] <AfC> fullermd: [in fact, more mistakes were being made on servers as a result of people sudoing when they shouldn't or, not using it when they should, etc etc etc]
[08:58] <fullermd> I've used pure sudo everywhere since sometime last millennium.  Makes management so much simpler.
[08:58] <AfC> {shrug} on desktops and other shared multi user systems, sure
[08:59] <fullermd> And saves all that trouble with connection sharing, X11 forwarding and key handling, blah blah blah.
[08:59] <AfC> right
[08:59] <AfC> so our definition of where the dividing line is is whether X is involved or not
[09:00] <AfC> anyway,
[09:00] <AfC> different key.
[09:00] <AfC> Good call.
[09:00] <AfC> fullermd: did the rest of http://thias.marmotte.net/2009/05/creating-a-restricted-bzrssh-smart-server/ look right to you? I've been trying to find an authoritative reference to that. Seems problematic to have to list all that stuff in so many people's home directories.
[09:01] <fullermd> It looked reasonable; I've never messed with it myself so I don't know if it's actually correct or works.
[09:11] <AfC> well, just tried the whole setup and it works... nice
[09:12] <AfC> yup, seems sound
[09:12]  * AfC should blog this
[09:14] <AfC> fullermd: thanks for your thoughts
[09:14] <fullermd> Yay, justified my oxygen use for the day.
[21:35] <mathrick> hey, is there an existing command to apply a patch that reverses an existing commit to the tree?
[21:36] <mathrick> ahh, merge
[22:03] <nebuPookins> I tried to do a checkout of a project from launchpad, but it seems to make bazaar crash.
[22:03] <nebuPookins> I posted the error message I get at https://bugs.launchpad.net/bzr/+bug/611949
[22:04] <nebuPookins> Wondering if anybody had any idea of what I could try next.
[22:09] <asabil> nebuPookins, just tried it over here, same issue
[22:10] <nebuPookins> Thanks; good to know it's not a config problem with my system.
[22:12] <nebuPookins> I'm also talking to the folks on #gnome-do
[22:13] <nebuPookins> Yeah, they said they're getting the same error too now. "I guess i haven't really rebranched lp:do for a long time"
[22:16] <asabil> there is already another bug open: https://bugs.launchpad.net/bzr/+bug/522637
[22:35] <lifeless> spiv was working on a fix
[22:35] <lifeless> I'm sorry that I don't know more than that
[22:38] <nebuPookins> Ok thanks, I'll subscribe that bug too.