[07:28] <GungaDin> How do I check a branch to a checkout after I've pushed it to a remote location?
[07:32] <mtaylor> 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] <mtaylor> GungaDin: or are you trying to modify your local branch to be a lightweight checkout of the remote location
[07:32] <mtaylor> ?
[07:34] <GungaDin> I'm trying to modify my local branch to be a checkout of the remote branch
[07:34] <GungaDin> which I think I've managed to do
[07:36] <mtaylor> GungaDin: awesome
[09:51] <lifeless> \o/
[10:10] <poolie> http://summit.ubuntu.com/uds-m/2010-05-11/
[10:12] <lifeless> abentley: http://www.huffingtonpost.com/2009/12/07/google-ceo-on-privacy-if_n_383105.html
[10:19] <thumper> poolie: if you are fixing things, there is the config locking problem that is biting us in the code import arena
[10:26] <poolie> hi there thumper
[10:26] <thumper> hi poolie
[10:27] <jelmer_> 'morning thumper
[10:28] <thumper> hi jelmer_
[10:28] <lifeless> jam: https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux/+bug/543617
[10:55] <lifeless> spiv: do we ahve something that waits for that part of the thread startup to have completed, in the 'main' thread ?
[10:55] <spiv> lifeless: as best I can tell, when the bind+listen happens, there should be no threads started yet
[10:56] <lifeless> spiv: theory: the thread starting the socketlistener which is itself a thread, is getting the timeslice before the new thread has started
[10:56] <spiv> The bind+listen happens in SocketListener.__init__
[10:56] <lifeless> yes
[10:57] <lifeless> I thought that is in the child thread though
[10:57] <lifeless> its a Threading.thread, right ?
[10:57] <spiv> SocketListener is a threading.Thread, yes
[10:58] <spiv> But it isn't started until after its __init__ returns
[11:28] <thumper> how do branches with symlinks work with windows?\
[11:28] <spiv> thumper: short answer is they don't
[11:29] <spiv> There's a plugin, though
[11:29] <thumper> spiv: which does what?
[11:29] <spiv> https://edge.launchpad.net/bzr-win32symlinks
[11:34] <thumper> nm
[11:34] <thumper> found a different way around it
[11:34] <Peng_> Good.
[11:34] <thumper> I'd like simple windows support without worrying about that
[11:34] <Peng_> Does bzr-win32symlinks even work? I'd heard that there were issues...
[11:35] <spiv> Peng_: the description on its LP page does pointedly say it isn't maintained anymore, so maybe not
[11:36] <Peng_> Whee.
[16:44] <uier> hi
[16:44] <uier> I need an uninstaller for Mac
[16:44] <uier> the one linked on the site doesnt work with snow leopard
[16:49] <uier> hrm
[16:49] <uier> anyone alive?
[16:50] <GaryvdM> Hi uier
[16:50] <uier> GaryvdM: hi!
[16:51] <GaryvdM> Not many people know much about the Mac installer.
[16:51] <uier> I installed Bazaar on Snow Leopard, but need to remove the bundle and everything it ever installed
[16:51] <uier> Oh no :(
[16:52] <GaryvdM> The person who does know in Gordan. He is not here.
[16:52] <GaryvdM> *is
[16:52] <uier> GaryvdM: What is his nickname
[16:55] <GaryvdM> uier: According to his lunchpad page, dOxxx
[16:56] <uier> It's kinda pointless offering an installer without a set in stone method of how to get it off your computer :|
[16:56] <uier> It should be bundled with an uninstaller
[18:25] <lifeless> -> food
[19:22] <kfogel> 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] <beuno> kfogel, try running that with -Dhpss
[19:23] <kfogel> beuno: srsly?
[19:23] <kfogel> beuno: ok, thanks
[19:23] <kfogel> beuno: on the server side, I assume you mean?
[19:23] <beuno> kfogel, it will give you more information
[19:23] <kfogel> beuno: aaaaaah
[19:23] <kfogel> got it
[19:23] <kfogel> -D for debug
[19:23] <beuno> kfogel, clientside
[19:23] <kfogel> beuno: thanks
[19:25] <kfogel> 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] <beuno> kfogel, awesome
[19:26] <beuno> kfogel, I have Dhpss enabled all the time
[19:26] <beuno> you can be cool as well by adding it to ~/bazaar/bazaar.conf
[19:26] <beuno> debug_flags = hpss
[19:27] <kfogel> beuno: done, in DEFAULT section
[19:27] <beuno> welcome to the club
[19:27] <kfogel> beuno: my next error is http://paste.ubuntu.com/431250/, which looks eminently googleable
[19:28] <beuno> wa
[19:28] <beuno> that's new to me
[19:28] <beuno> so
[19:28] <beuno> I assume the server has an old version of bzr
[19:29] <kfogel> beuno: except I just built the server myself from bzr 2.1 sources...
[19:29] <beuno> kfogel, both server and client on 2.1?
[19:29] <kfogel> beuno: hmmm, except locally I seem to be running 2.2dev, which I didn't realize
[19:29] <kfogel> beuno: though you'd think that wouldn't be a problem
[19:29] <beuno> I wouldn't
[19:29] <beuno> kfogel, did the server have another version of bzr installed?
[19:30] <beuno> the smart server may be invoking a different bzr on the server
[19:30] <beuno> this looks like a bug for spiv though
[19:30] <beuno> I would absolutely report it
[19:31] <kfogel> 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] <TresEquis> kfogel: when the client sets up the session, it may not find your preferred bzr
[19:32] <kfogel> 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] <kfogel> 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] <kfogel> Not that that has anything to do with Bazaar, of course :-).
[19:36] <TresEquis> Such a brew might help get coding done faster ;)
[19:37] <TresEquis> Elat Ale would be shorter
[19:37] <TresEquis> or Elan
[19:38] <kfogel> TresEquis: nice!  I think we've got the makings of a fine brewing company here...
[19:46] <jam> kfogel, beuno: known bug of bzr talking to an older server
[19:46] <jam> I would check your path
[19:46] <jam> and remember that it probably doesn't include any user customizations
[19:46] <jam> because it is only what 'ssh' gets before launching bash
[19:47] <kfogel> 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] <jam> kfogel: you probably only have /usr/bin and /usr/local/bin
[19:47] <jam> you should be able to set
[19:48] <jam> BZR_REMOTE_PATH=/the/one/I/really/want/bzr bzr FOO
[19:48] <jam> and that should work
[19:48] <jam> which hints you want to fix the system path, or something
[19:48] <kfogel> jam: well, the "other" one is ~root/kfogel/bzr-2.1.0/bzr, but yeah
[19:48] <kfogel> jam: hunh, that BZR_REMOTE_PATH is something you can set on the client side??
[19:49] <jam> kfogel: yes
[19:50] <jam> you can also set something bazaar.conf/locations.conf
[19:50] <jam> kfogel: bzr_remote_path=XXX
[19:50] <jam> so you could put
[19:50] <jam> [bzr+ssh://myhost]
[19:50] <jam> bzr_remote_path=/home/root/kfogel/...
[19:50] <jam> bzr_remote_path:policy = recurse
[19:51] <kfogel> jam: thanks
[19:52] <kfogel> 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] <jam> kfogel: right, the env_var overrides config, etc
[19:53] <jam> the config is so you can set up a specific site to be different from all others
[19:53] <jam> certainly you don't want that env var when pushing to LP, for example
[19:55] <kfogel> 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] <kfogel> .
[20:43] <jam> kfogel: did you get it workinG?
[20:53] <kfogel> 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] <kfogel> jam: this is for the GNU Emacs bzr+ssh:// thang, btw
[20:54] <kfogel> davidstrauss: hey, your branch delay problem all solved, right?  (from last week)
[23:02] <davidstrauss_> kfogel: yes, thanks
[23:19] <Socket_77> Hello
[23:19] <Socket_77> Is there anyway to get bzr to preserve the timestamp on an add/commit?
[23:19] <Socket_77> and subsequently on a checkout?