[00:01] jelmer, paths [00:02] 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] lokkju: yes, that might very well be possible [00:06] 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] ack, 32K === r0bby is now known as robbyoconnor [08:38] How can you restrict bzr+ssh to a specified directory path rather than bzr+ssh+//user@hostname/path implyng / ? [08:39] 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] authorized_keys entries are server-side... [08:42] fullermd: oh, [08:42] duh [08:42] right [08:42] Ok, so maybe a different question [08:43] * fullermd gets you an extra coffee mug 8-} [08:43] That's fine for users who are *only* doing bzr+ssh when they connect, [08:43] but what about users who also have normal accounts there? [08:43] (ie, me as opposed to everyone else) [08:44] 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] fullermd: to have bzr+ssh://research.operationaldynamics.com/bzr/java-gnome/mainline/ for pushing, rather than the current [08:44] Clean and/or pure-bzr solutions? I don't know of any. I can dream up a few somewhat hackish things. [08:45] Of course, you can use authorized_keys and use different keys, which isn't without drawbacks. [08:45] fullermd: too-muc-info bzr+ssh://epsilon.dal.operationaldynamics.com/export/web/com/operationaldynamics/research/bzr/java-gnome/mainline/ [08:45] (but can work, depending) [08:45] I mean, obviously I could put a symlink in / as /bzr -> path, but that seems so wrong [08:46] I'm wondering if sshd gets any information about the hostname that was requested [08:46] Marginally less wrong would be a symlink at ~/bzr and bzr+ssh://blah/~/bzr/ of course. [08:46] (outbound, ssh_config keys on hostname target [08:46] I don't think so. [08:46] what about receiving side in [well, not sshd_config, but something?) [08:47] fullermd: actually, yeah, the home directories might be a better option, in the final analysis. [08:47] hm [08:47] right now we have a shared repo, but... [08:48] Well, I didn't mean _moving_ stuff under homedirs, just adding the symlink for shorter typing on access. [08:49] oh [08:49] hm [08:49] {shrug} [08:49] yeah, [08:49] that's not bad [08:50] fullermd: good thinking [08:50] 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] yeah, I'm just pondering along those lines [08:50] maybe [08:51] well, maybe a different sshd instance on a different port [08:51] or some kind of port forwarding, or... [08:51] hm [08:51] 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] Different port wouldn't gain you anything over using a separate key with the authorized_keys fiddling. [08:51] yeah [08:52] damn [08:52] this seems like it should be simple [08:52] well [08:53] 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] Or you could pretend you're Launchpad, and just build your whole thing on top of a fictitious pseudofs :p [08:53] You can have multiple keys. Just have a special one for bzr stuff. [08:54] 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] 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] well, [08:54] yeah [08:54] duh [08:54] that could work [08:54] client side, ssh_config [08:54] specify a different IdentityFile [08:54] Well, if you wanted to go systemwide... [08:55] yeah, I meant .ssh/config [08:55] nice [08:55] 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] sort of a bother to have to have another key, but hey, yes, I'll live [08:55] Of course, given the sorry state of manglement for connection sharing... [08:55] yeah [08:56] 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] Sure, but who ssh's as root? :p [08:56] (I also noticed that even user@ and user@ has a lot of ugly race conditions if you start doing any port forwarding [08:56] fullermd: not me, of course. [08:57] fullermd: [our security team had a hard think about that, and decided that inhibiting sysadmins from being root was stupid] [08:57] 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] I've used pure sudo everywhere since sometime last millennium. Makes management so much simpler. [08:58] {shrug} on desktops and other shared multi user systems, sure [08:59] And saves all that trouble with connection sharing, X11 forwarding and key handling, blah blah blah. [08:59] right [08:59] so our definition of where the dividing line is is whether X is involved or not [09:00] anyway, [09:00] different key. [09:00] Good call. [09:00] 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] It looked reasonable; I've never messed with it myself so I don't know if it's actually correct or works. [09:11] well, just tried the whole setup and it works... nice [09:12] yup, seems sound [09:12] * AfC should blog this [09:14] fullermd: thanks for your thoughts [09:14] Yay, justified my oxygen use for the day. [21:35] hey, is there an existing command to apply a patch that reverses an existing commit to the tree? [21:36] ahh, merge [22:03] I tried to do a checkout of a project from launchpad, but it seems to make bazaar crash. [22:03] I posted the error message I get at https://bugs.launchpad.net/bzr/+bug/611949 [22:03] Launchpad bug 611949 in Bazaar "bzr crashes during checkout of gnome-do (affected: 1, heat: 6)" [Undecided,New] [22:04] Wondering if anybody had any idea of what I could try next. [22:09] nebuPookins, just tried it over here, same issue [22:10] Thanks; good to know it's not a config problem with my system. [22:12] I'm also talking to the folks on #gnome-do [22:13] 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] there is already another bug open: https://bugs.launchpad.net/bzr/+bug/522637 [22:16] Launchpad bug 522637 in Bazaar "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 11, heat: 60)" [High,In progress] [22:35] spiv was working on a fix [22:35] I'm sorry that I don't know more than that [22:38] Ok thanks, I'll subscribe that bug too.