[07:28] How do I check a branch to a checkout after I've pushed it to a remote location? [07:32] GungaDin: do you mean you've pushed to a remote location and now you want to get new changes that might be in that remote location? [07:32] GungaDin: or are you trying to modify your local branch to be a lightweight checkout of the remote location [07:32] ? [07:34] I'm trying to modify my local branch to be a checkout of the remote branch [07:34] which I think I've managed to do [07:36] GungaDin: awesome === rml_ is now known as rml [09:51] \o/ [10:10] http://summit.ubuntu.com/uds-m/2010-05-11/ [10:12] abentley: http://www.huffingtonpost.com/2009/12/07/google-ceo-on-privacy-if_n_383105.html [10:19] poolie: if you are fixing things, there is the config locking problem that is biting us in the code import arena [10:26] hi there thumper [10:26] hi poolie [10:27] 'morning thumper [10:28] hi jelmer_ [10:28] jam: https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux/+bug/543617 [10:28] Launchpad bug 543617 in linux "Unmount of an fs with dirty cache buffers causes pathological slowdown" [High,Fix released] [10:55] spiv: do we ahve something that waits for that part of the thread startup to have completed, in the 'main' thread ? [10:55] lifeless: as best I can tell, when the bind+listen happens, there should be no threads started yet [10:56] spiv: theory: the thread starting the socketlistener which is itself a thread, is getting the timeslice before the new thread has started [10:56] The bind+listen happens in SocketListener.__init__ [10:56] yes [10:57] I thought that is in the child thread though [10:57] its a Threading.thread, right ? [10:57] SocketListener is a threading.Thread, yes [10:58] But it isn't started until after its __init__ returns === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila (not)| bzr 2.1.1 is out === arnarl_ is now known as arnarl [11:28] how do branches with symlinks work with windows?\ [11:28] thumper: short answer is they don't [11:29] There's a plugin, though [11:29] spiv: which does what? [11:29] https://edge.launchpad.net/bzr-win32symlinks [11:34] nm [11:34] found a different way around it [11:34] Good. [11:34] I'd like simple windows support without worrying about that [11:34] Does bzr-win32symlinks even work? I'd heard that there were issues... [11:35] Peng_: the description on its LP page does pointedly say it isn't maintained anymore, so maybe not [11:36] Whee. === gnomefreak76 is now known as gnomefreak === radoe_ is now known as radoe === herb__ is now known as herb === jelmer_ is now known as jelmer [16:44] hi [16:44] I need an uninstaller for Mac [16:44] the one linked on the site doesnt work with snow leopard [16:49] hrm [16:49] anyone alive? [16:50] Hi uier [16:50] GaryvdM: hi! [16:51] Not many people know much about the Mac installer. [16:51] I installed Bazaar on Snow Leopard, but need to remove the bundle and everything it ever installed [16:51] Oh no :( [16:52] The person who does know in Gordan. He is not here. [16:52] *is [16:52] GaryvdM: What is his nickname [16:55] uier: According to his lunchpad page, dOxxx [16:56] It's kinda pointless offering an installer without a set in stone method of how to get it off your computer :| [16:56] It should be bundled with an uninstaller === beuno is now known as beuno-lunch === ubott2 is now known as ubottu [18:25] -> food === beuno-lunch is now known as beuno [19:22] lifeless, jam: care to play Captain Obvious in helping me debug "bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist." ? I've done the googling and stuff, and tried writing a log. No luck so far. privchat if have time to chat [19:22] kfogel, try running that with -Dhpss [19:23] beuno: srsly? [19:23] beuno: ok, thanks [19:23] beuno: on the server side, I assume you mean? [19:23] kfogel, it will give you more information [19:23] beuno: aaaaaah [19:23] got it [19:23] -D for debug [19:23] kfogel, clientside [19:23] beuno: thanks [19:25] beuno: Hah! Brilliant. It told me "HPSS calls: 1 (0 vfs) SmartSSHClientMedium(bzr+ssh://None@hostname.I'm.trying.to.reach/)", and when I saw the "None" I realized I probably needed a different username than "kfogel". Putting one there got me to my next error, and I am on my merry way. [19:25] kfogel, awesome [19:26] kfogel, I have Dhpss enabled all the time [19:26] you can be cool as well by adding it to ~/bazaar/bazaar.conf [19:26] debug_flags = hpss [19:27] beuno: done, in DEFAULT section [19:27] welcome to the club [19:27] beuno: my next error is http://paste.ubuntu.com/431250/, which looks eminently googleable [19:28] wa [19:28] that's new to me [19:28] so [19:28] I assume the server has an old version of bzr [19:29] beuno: except I just built the server myself from bzr 2.1 sources... [19:29] kfogel, both server and client on 2.1? [19:29] beuno: hmmm, except locally I seem to be running 2.2dev, which I didn't realize [19:29] beuno: though you'd think that wouldn't be a problem [19:29] I wouldn't [19:29] kfogel, did the server have another version of bzr installed? [19:30] the smart server may be invoking a different bzr on the server [19:30] this looks like a bug for spiv though [19:30] I would absolutely report it [19:31] beuno: yes, the server has a much older version of bzr installed in /usr/bin/bzr, and (in theory) that's not supposed to infect the 2.1 build that I'm using. But it could be, somehow. [19:31] kfogel: when the client sets up the session, it may not find your preferred bzr [19:32] TresEquis: could be. I'm trying to puzzle out how; on this machine, there is a restricted shell that (in theory) should be fired up, and then it should exec a particular bzr that I have configured it to exec. [19:33] TresEquis: regarding your nick: I've often wanted to brew and sell a brand of beer called "Regal XXX Lager" (the world's first palindromic beer). [19:34] Not that that has anything to do with Bazaar, of course :-). [19:36] Such a brew might help get coding done faster ;) [19:37] Elat Ale would be shorter [19:37] or Elan [19:38] TresEquis: nice! I think we've got the makings of a fine brewing company here... [19:46] kfogel, beuno: known bug of bzr talking to an older server [19:46] I would check your path [19:46] and remember that it probably doesn't include any user customizations [19:46] because it is only what 'ssh' gets before launching bash [19:47] jam: thanks. I think (from other debugging just now) that the bzr I want to be invoked is not the one being invoked, on the server side; checking... [19:47] kfogel: you probably only have /usr/bin and /usr/local/bin [19:47] you should be able to set [19:48] BZR_REMOTE_PATH=/the/one/I/really/want/bzr bzr FOO [19:48] and that should work [19:48] which hints you want to fix the system path, or something [19:48] jam: well, the "other" one is ~root/kfogel/bzr-2.1.0/bzr, but yeah [19:48] jam: hunh, that BZR_REMOTE_PATH is something you can set on the client side?? === mithrandi is now known as idnaria [19:49] kfogel: yes [19:50] you can also set something bazaar.conf/locations.conf === gnomefreak76 is now known as gnomefreak [19:50] kfogel: bzr_remote_path=XXX [19:50] so you could put [19:50] [bzr+ssh://myhost] [19:50] bzr_remote_path=/home/root/kfogel/... [19:50] bzr_remote_path:policy = recurse [19:51] jam: thanks [19:52] jam: when doing it on the command line, there's no need for that "policy = recurse", though, because I'm naming the branch address explicitly anyway, right? [19:53] kfogel: right, the env_var overrides config, etc [19:53] the config is so you can set up a specific site to be different from all others [19:53] certainly you don't want that env var when pushing to LP, for example [19:55] jam: certainly not :-). And in general not -- in this case, the end goal is a situation where the remote side's restricted shell DTRT and people can just use bzr+ssh:// without any special config or env vars. So I'm going to just do it on the cmdline; that way I know I won't let it continue too long [19:55] . [20:43] kfogel: did you get it workinG? [20:53] jam: not yet, but problem now is not in bzr, it's in existence of user accounts on the remote box, so I'm working on that [20:53] jam: this is for the GNU Emacs bzr+ssh:// thang, btw [20:54] davidstrauss: hey, your branch delay problem all solved, right? (from last week) [23:02] kfogel: yes, thanks [23:19] Hello [23:19] Is there anyway to get bzr to preserve the timestamp on an add/commit? [23:19] and subsequently on a checkout?