[00:37] <rockstar> I've just done a bzr checkout of an svn repo (using bzr-svn).  Problem is, when I bzr push the checkout to a branch, I get "bzr: ERROR: At lp:~entertainer-releases/entertainer/devel you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. Please move the target directory out of the way and try again."
[00:37] <rockstar> Is there a way to work around this?
[00:38] <jelmer> rockstar: can you try pushing to a slightly different location?
[00:39] <jelmer> It might be that there's an incomplete branch around
[00:40] <lifeless> rockstar: push --use-existing-dir
[00:43] <rockstar> lifeless, same error
[00:48] <Peng> rockstar: You're using a checkout? Like, "bzr checkout"?
[00:48] <mwhudson> i guess sftp in an rm .bzr should work
[00:48] <rockstar> Peng, yea, bzr checkout http://<path-to-svn>
[00:48] <rockstar> mwhudson, ?
[00:49] <Peng> It's possible to push from a checkout?
[00:49] <lifeless> mwhudson: I think the sftp server prhobits that
[00:49] <lifeless> rockstar: bzr init --rich-root-pack URL might work
[00:50] <rockstar> lifeless, will that kill my bzr log?
[00:50] <lifeless> rockstar: EPARSE
[00:51] <rockstar> Well, the thing I'm trying to accomplish is pretty much a conversion from svn to bzr.  I want to keep the versioning.
[00:51] <lifeless> of course
[00:51] <rockstar> I was just wondering if a bzr init would blow out the past versioning
[00:52] <lifeless> no
[00:52] <lifeless> bzr init prepares a fresh database
[00:52] <rockstar> And the versions are stored in the database?
[00:53] <lifeless> uh
[00:53] <lifeless> we have lots of things that are versioned
[00:53] <rockstar> s/are/aren't/
[00:53] <lifeless> can you be more specific ?
[00:53] <rockstar> Okay, the output of bzr log, along with the actual changesets
[00:53] <lifeless> I'm saying create a fresh database on lp
[00:53] <lifeless> that you then push into
[00:54] <Peng> rockstar: If there was already a branch at the location, "bzr init" would error out.
[00:54] <spiv> rockstar: init'ing a repo on a remote server isn't going to affect the history you have locally.
[00:54] <rockstar> Ah, on the destination.
[01:03] <rockstar> I think this bazaar version is just too old.
[01:04] <lifeless> what version is it?
[01:05] <rockstar> 0.90
[01:05] <rockstar> :)
[01:05] <lifeless> yes, please run something created this millenium
[01:05] <rockstar> Yea, I guess this is the default in gutsy
[01:07] <Peng> It is.
[01:07] <Peng> You can use bzr's deb repo thingy. https://launchpad.net/bzr/+archive
[01:07] <Peng> Or upgrade to Hardy, which almost has the newest version of bzr.
[01:09] <rockstar> Peng, yes, but there's currently no bzr-svn for 1.5
[01:09] <jelmer> rockstar, https://lists.ubuntu.com/archives/bazaar-announce/2008-May/000149.html
[01:09] <rockstar> And I tried building my own package, and it doesn't seem to like life
[01:09] <jelmer> no PPA yet though
[01:10] <rockstar> jelmer, thanks, I'm on that list
[01:10] <nysin> Is there documentation somewhere on the intended usage pattern of bzr-gtk? It looks like it only pays attention to the this/other/base files, but then doesn't fold that back to the non-this/other/base files. How is one intended to bridge that?
[01:10] <rockstar> Er, no bzr svn for 1.4.  1.5 is just barely rc
[01:10] <jelmer> rockstar: see that link - that's bzr-svn for bzr 1.4
[01:10] <nysin> gconflicts in particular
[01:10] <rockstar> Ah, the ppa must be broken.
[01:11] <rockstar> I saw an email on the list that said "since 1.4 and 1.5 are coming out so close together, there won't be a ppa release of bzr-svn for 1.4" and thought there would be a release.
[01:11] <jelmer> rockstar: I announced I wouldn't do a release a the same time as bazaar 1.4
[01:12] <jelmer> The bzr-svn intended to work with 1.5 also happens to work with 1.4
[01:12] <rockstar> Ah, I see.
[01:12] <rockstar> Regardless, it's working now.
[01:13] <Peng> OMG! New bzr-svn! Yay!
[01:13] <jelmer> (-:
[01:14] <Peng> Since I always run bzr.dev, it's been a long time since I've had bzr-svn working.
[01:18] <thumper> rockstar: you should have the ~bzr PPA in your sources.list :-)
[01:19] <Peng> Huh. bzr co has a -r option, but up does not.
[01:19]  * Peng uses revert, then.
[01:19] <rockstar> thumper, I do.  I was working on another system
[01:19] <thumper> ah
[01:19]  * rockstar has more than one system...  :)
[01:23] <Peng> jelmer: BTW, from when I ran pyflakes/pylint, there are quite a lot of unused imports.
[01:24] <jelmer> Peng: patches are welcome :-)
[01:26] <Peng> Hmm.
[01:26] <Peng> I think I actually got all of the imports.
[01:28] <Peng> I stopped working on it a bit after that and never got back to it.
[01:28] <bob2> "someone" should add lazy_import support to pyflakes/lint
[01:30] <Peng> bzr-svn doesn't lazy_import much, so it wasn't a big problem.
[01:30] <bob2> ah
[01:31] <Peng> Now, all of the whining about too many methods or too many arguments or too many lines, that was annoying.
[01:31] <spiv> bob2: there is a pyflakes branch with lazy_immport support
[01:31] <jelmer> pylint gives a lot of output and a lot of it is not actually fixable in bzr-svn (such as classes having to much methods or functions having too much arguments)
[01:31] <spiv> bob2: thanks to mwhudson, IIRC.  You can find it on lp.
[01:31] <jelmer> Peng, yeah, indeed
[01:32] <bob2> oh, awesome
[01:35] <spiv> bob2: yeah, it is awesome
[01:35] <bob2> also awesome is the "notification" plugin
[01:35] <Peng> jelmer: The thing is, my linted branch has lots of XXX comments strewn about about things I didn't know how to resolve.
[01:36] <mwhudson> getting pylint to be useful is A Project
[01:43] <rockstar> mwhudson, yea, I'm dealing with that right now...
[02:11] <beuno> abentley, BB web interface seems to be hung up  (email works though)
[02:16] <Peng> bzr: ERROR: You must have a branch nickname set to loomify a branch
[02:16] <Peng> :(
[02:16] <abentley> beuno: It auto-restarted a minute ago.  Should be fine now.
[02:17] <beuno> abentley, ah, thanks.  Is this because of sqlite, or something else?
[02:17] <Peng> Oh, ok.
[02:18] <abentley> beuno: It's an unfortunate interaction between TurboGears and SQLite.
[02:20] <beuno> abentley, ah, because I want to use BB for a project of mine, and I was thinking of porting the backend to mysql (which I know better then postgre)
[02:20] <beuno> bot sure if that's something you'd like to see done
[02:21] <beuno> s/bot/but
[02:23] <Peng> abentley: bzrtools needs its version compatibility thingy updated for bzr.dev.
[02:36] <jelmer> Does anybody have experience with the redmine bug tracker?
[03:01] <igc> jelmer: when you get a moment, can you double check my write up re bzr-svn in the User Guide?
[03:01] <igc> see http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#bzr-svn
[03:02] <igc> I probably ought to give an explicit svn-import example
[03:02] <igc> anything else?
[03:02] <jelmer> igc: Sure, I'll have a look now
[03:03] <igc> thanks
[03:05] <jelmer> igc: svn-push is only required when creating a new branch in Subversion, you should be able to just use "bzr push"
[03:06] <igc> jelmer: ah good
[03:07] <igc> I was wondering whether there was any other need for using svn-push over push
[03:07] <igc> sounds like there isn't?
[03:07] <igc> jelmer: the help did say svn-push would go away one day
[03:08] <igc> is that some time off still?
[03:08] <jelmer> igc: renames are supported (pushing into svn and then pulling those changes back in from svn works) but copy tracking isn't imported
[03:08] <jelmer> igc: yep, that's still the plan but it depends on some changes in bzr itself
[03:09] <jelmer> bug 121875
[03:09] <igc> jelmer: any magic source for keeping a bzr repo mirror in sync?
[03:09] <igc> e.g. a std svn hook we suggest?
[03:10] <jelmer> igc: not really - you can just use "bzr pull" like you would for keeping a mirror of a bzr branch in sync
[03:10] <jelmer> "bzr svn-import" is incremental and can be used for full repositories
[03:11] <jelmer> igc: there's also a small typo; s/0.49/0.4.9/ for the version number
[03:12] <igc> jelmer: any idea how most bzr-svn are keeping mirrors in sync? cron jobs with svn-import or pull mainly?
[03:13] <jelmer> I think so, yes
[03:13] <jelmer> I personally just run pull manually whenever I need the mirror
[03:18] <jelmer> igc: having an example use of svn-import up there may indeed be useful as well
[03:18] <igc> jelmer: yes I think so too
[03:22] <jelmer> Verterok: w00t on the DMG :-)
[03:22] <Verterok> jelmer: Hi :-)
[03:26] <Verterok> jelmer: right now I'm trying to build the minimal dependencies (svn client + libs + svn-python), but it's not working as expected :(
[03:26] <jelmer> Verterok: you're building subversion 1.5?
[03:27] <Verterok> sort of :P, only trying to get the minimal dependencies to run bzr-svn
[03:27] <Verterok> but the simples solution to make it available for bzr-1.5, is to bundle bzr-svn in OS X dmg, and point to the subversion dmg
[03:28] <jelmer> That would be a huge improvement over the current situation
[03:28] <jelmer> including the svn bits in the Bazaar dmg would be nice but may not be worth the effort
[03:29] <Verterok> that's my conclusion too...after a few hours trying to get it working
[03:32] <Verterok> jelmer: for the moment I can build the Tiger dmg (no Leopard yet), but I think I achieved building a universal installer (I can easily add bzr-svn to it) for Tiger...now I only need a mac intel with triger to test it :P
[03:33] <jelmer> Verterok: awesome, thanks ! :-) There's been quite a few people asking about this...
[03:35] <Verterok> np ;)
[03:36]  * Verterok looking for a owner of mac intel with Tiger (to help beta test the installer)  
[03:49] <michalski> hello, problem: typing this in the terminal: ----> bzr push lp:~michalski/+junk/vector-core
[03:49] <michalski> returns error:   bzr: ERROR: Transport operation not possible: http does not support mkdir()
[03:50] <Peng> michalski: You're trying to push over http.
[03:50] <michalski> how do i do so differently
[03:50] <Peng> michalski: You should run "bzr launchpad-login" to log in to LP, and it'll start pushing over bzr+ssh.
[03:50] <michalski> ah ok :)
[03:50] <Peng> michalski: What version of bzr?
[03:50] <michalski> not 100% sure but im guessing the latest
[03:51] <michalski> it says: No Launchpad user ID configured.
[03:51]  * igc lunch
[03:51] <michalski> how do i do this?
[03:51] <Peng> michalski: Oh.
[03:52] <Peng> michalski: "bzr launchpad-login michalski" or whatever your username is, then.
[03:53] <michalski> success :) thanks
[03:53] <michalski> peng
[03:53] <michalski> :)
[03:53] <Peng> :)
[03:53] <michalski> goodnight
[03:53] <Peng> Good night.
[04:07] <jelmer> igc, is there a particular reason rebase is discussed under "pseudo merging" rather than "brief tour of popular plugins" ?
[04:07] <jelmer> I personally like how that bit is done better because users will likely not care how certain functionality is provided
[04:08] <jelmer> (e.g. just having a note for some bits of the user guide saying "this functionality requires plugin X")
[04:10] <jelmer> anyway, just my €0,02
[04:16] <Verterok> jelmer: running selftest svn (OS X) I get this: http://rafb.net/p/qutRww45.html
[04:16] <Verterok> any ideas?
[04:17] <jelmer> ah, ouch
[04:17] <jelmer> please file a bug about that bit
[04:17] <jelmer> looks like I broke compatibility with subversion 1.5
[04:17] <Verterok> ah, it's fresh branch of trunk
[04:17] <Verterok> ups
[04:18] <Verterok> ok, I'll fill a bug then. should I add any additional info?
[04:19] <jelmer> nope, that should be sufficient
[04:19] <Verterok> ok, thanks
[04:41] <igc> jelmer: no deep reason. the plugins chapter didn't exist when I wrote the rebase stuff
[04:41] <igc> jelmer: for the reasons you outline though, I didn't feel compelled to move it
[05:08] <huyx> 你好
[05:24] <bignose> I love bzr shell. I love ssh-agent.
[05:24] <bignose> I'm less enamoured of gpg-agent.
[05:25] <lifeless> I haven't sipped from that fountain yet
[05:25] <bignose> It only seems to remember my "secret key is unlocked" state for five minutes or so, and I can't find any configuration to turn it off.
[05:25] <lifeless> I'm still using gnome-gog
[05:25] <lifeless> *gnome-gpg* I mean
[05:25] <bignose> which clangs horribly compared to 'ssh-agent', that simply remembers I've unlocked my key for the entire session.
[05:26] <bignose> well, my sessions last longer than my GNOME session, since I reconnect to my screen session.
[05:45]  * igc picking up kids - bbiab
[05:49] <abentley> Peng: I've updated bzrtools' version number on the dev branch.
[05:50] <bob2> ooh, and it ate 'heads'
[05:51] <Peng> abentley: Thank you! :)
[05:52] <Peng> bob2: Wait, what did you mean by "ate"?
[05:53] <Peng> That's neat that heads is a part of bzrtools now.
[05:53] <Peng> And I just installed it like last week. :P
[05:53] <abentley> bob2: Yeah, heads is really useful when you need it, so I wanted to get it broader distribution.
[05:54] <fullermd> Ooh, nifty.
[05:54] <abentley> Also I'll be ensuring it's maintained.
[06:04] <bignose> so what do folks use to ensure their 'bzr shell' in a 'screen' session keeps the GPG key open?
[06:05] <bignose> if 'gpg-agent', then how did you configure it to stop forgetting the key every few minutes?
[07:04] <lifeless> I'm done, later all
[07:23] <Verterok> I just uploaded a universal installer for 10.4 (Tiger), I can't test if it works in i386 arch...beta testers are welcome :)
[07:23] <i386> Verterok: oh nice - only tested on PPC?
[07:24] <Verterok> i386: yep, I don't have mac intel...yet
[07:24] <i386> ahh
[07:24] <i386> Ill test it if you want
[07:24] <Verterok> that would be great! :D
[07:25] <i386> is it on the website?
[07:25] <Verterok> yes: http://launchpad.net/bzr/1.4/1.4/+download/Bazaar-1.4-OSX10.4-universal-1.dmg
[07:37]  * Verterok heading to bed...
[07:38] <Verterok> i386: thanks for testing the installer, if you encounter any trouble with the installer, please contact me IRC or mail (I'll check IRC in the morning)
[08:06] <igc> jamesh: see the bzr mailing list for a Python string concatenation test program. Can you please check I'm not doing something dumb? :-)
[08:09] <jamesh> igc: note that there are a few different cases to consider
[08:09] <jamesh> igc: in the case that was being discussed, we had a list containing all the strings to be concatenated as the starting point
[08:10] <jamesh> your test program starts with a file descriptor and incrementally reads in the data
[08:10] <jamesh> so it really depends on what you want to test
[08:12] <jamesh> as for measuring the memory usage, valgrind's massif tool might be a good way to compare the algorithms
[08:17] <igc> jamesh: yeah - my test program reflects exactly what happens in bzr-fastimport
[08:17] <igc> it's actually reading a # of bytes from a stream and tracking line #s as it goes: hence the readline approach
[08:18] <jamesh> igc: right.  So the optimal code for fastimport might be different to the optimal code for knit.py
[08:20] <jamesh> igc: unrelated to the concatenation bit, using the file object as an iterator will be faster than repeatedly calling readline()
[08:20] <jamesh> iirc
[08:20] <jamesh> it definitely was in older versions (reading the file in larger chunks)
[08:21] <igc> sure - I actually pass the blob size to readline though so I suspect I need to keep using it
[08:21] <Peng> I think iterating over the file object buffers more than calling readline().
[08:22] <jamesh> igc: the size arg to readline() just limits how much data it will return
[08:22] <jamesh> igc: iter() protocol reads larger blocks from the file then returns successive lines from those blocks
[08:22] <igc> I know - and I need to do that to follow the git-fastimport spec
[08:23] <igc> i.e. there's no certainty the blob will be newline terminated
[08:23] <jamesh> igc: so you just use read(size_of_blob) for the blob, right?
[08:25] <igc> that won't track the newlines for me though
[08:25] <igc> perhaps I can scan the blob after the fact though
[08:41] <jamesh> igc: blob.count('\n') might be what you want then
[08:42] <jamesh> igc: count() also takes optional start/end arguments in case you want to carve up even larger string blocks
[08:42] <igc> jamesh: cool - I'll try that
[08:44] <igc> jamesh: the only issue then is whether \n is good enough for newline detection on Windows
[08:44] <jamesh> igc: the answer to that will depend on whether fastimport data streams are considered to be text or binary
[08:45] <jamesh> igc: if they contain binary data inline, then they probably need to be handled as binary
[08:45] <jamesh> in which case line endings should always be \n
[08:45] <igc> both :-)
[08:45] <igc> they contain binary
[08:45] <igc> but we report reports in turns of text line #s
[08:46] <igc> s/reports/errors/
[08:46] <jamesh> igc: so if I have a binary file that happens to contain '\n', would it be represented as '\n' or '\r\n' in the stream?
[08:46] <jamesh> if the file format depends on switching back and forth between text and binary mode, then it sounds broken :)
[08:47] <igc> the binary content would be exactly as is
[08:48] <igc> but it's a line-based format otherwise
[08:48] <jamesh> it sounds like the file needs to be treated as binary then
[08:48] <igc> with a size indicator given on the line above where binary content starts
[08:49] <igc> jamesh: I think count('\n') will be good enough
[08:51] <jamesh> igc: http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html seems to indicate a binary file format where newlines are represented by \n
[08:53] <bignose> so what do folks use to ensure their 'bzr shell' in a 'screen' session keeps their GPG secret key open?
[08:53] <bignose> if 'gpg-agent', then how did you configure it to stop forgetting the key every few minutes?
[08:55] <AfC> Ah! bzr 1.4 is available now. Terrific.
[08:56] <RAOF> bignose: You should be able to pass in --default-cache-time or somesuch; that's what I've done in the past.
[08:56] <AfC> bignose: put a gpg-agent.conf in your ~/.gnupg directory
[08:56] <AfC> bignose: the parameters you want are default-cache-ttl and
[08:56] <AfC> bignose: max-cache-ttl
[08:57] <AfC> The defaults are to expunge your keys in time frames on the order of minutes, which I find just a little too aggressive.
[08:58] <AfC> [I mean, shit, day or week is fine; if you're being paranoid then half day or hour or even half hour, but _minutes_?]
[08:58] <bignose> so how can I make it *never* expire, the way 'ssh-agent' works?
[08:59] <AfC> [we use heuristics to flush keys anyway if certain actions have occurred, but in practise we find reboots to do the trick]
[08:59] <bignose> my sessions commonly live for many months.
[08:59] <AfC> bignose: put a rather large number of seconds in those settings.
[08:59] <bignose> so a setting of 0 won't do it?
[08:59] <AfC> bignose: it didn't seem to, but maybe I was being misled.
[08:59] <jamesh> AfC: so I suppose you're not one of those people who carry half their PGP key around on a USB key?
[09:00] <AfC> (it might have disabled caching all together)
[09:00] <AfC> jamesh: uh, no.
 doesn't indicate what a value of 0 will do.
[09:00] <bignose> I guess I'll just have to experiment.
[09:00] <jamesh> AfC: I do know people who have things set up so they can recover their PGP key with a USB key plus their desktop or laptop, or with just the desktop and laptop together
[09:01] <jamesh> having just one is not enough
[09:01] <bob2> using par or something?
[09:01] <bignose> AfC, RAOF: thanks for the helpful response.
[09:01] <jamesh> bob2: gfshare
[09:01] <AfC> jamesh: Oh, I'm a big fan of two factor authentication, but I just never managed to make it work. (eg, there is an SD slot in this damn thing, but I haven't managed to get that to work yet, etc)
[09:14]  * igc dinner
[09:32]  * awilkins used to do smartcard developmen and has never bothered with 2-factor auth apart from his work-supplied RSA secureid
[09:32] <awilkins> My work it are now planning to only allow read-only access to unencrypted USB keys :-(
[09:33] <awilkins> Very irritating ; I don't deal with any classified data, so it just stops me using a BZR repo on my USB key to work at home.
[09:40] <AfC> awilkins: (obviously the mechanism for reading encrypted devices is not something you are able to replicate elsewhere. Interesting)
[09:43] <awilkins> AfC: It's some proprietary piece of crap
[09:43] <awilkins> "SafeBoot"
[09:44] <AfC> The vogue at a number of our clients has been to use hardware VPN devices and to only allow people to connect to foreign networks through such devices
[09:45] <AfC> which leads to the poor shmucks carrying around this heavy module strapped to the back of their laptop's monitor to then go to either ethernet or a PCMCIA wifi card.
[09:45] <AfC> and, of course, a neato hard-to-use pain-in-the-ass web interface to control the thing.
[09:45] <AfC> "usability"
[09:45] <awilkins> Nasty. We have to use Cisco VPN, but with the "Windows Firewall" setting on
[09:46] <awilkins> So I can't use my router as a VPN bridge with vnpc
[09:46] <AfC> [like, "if you connect your laptop to a foreign network not through this device, your employment be terminated. Immediately"]
[09:46] <AfC> awilkins: annoying
[09:47] <awilkins> Yeah, I usually prefer to shove my laptop under the desk and remote desktop it on my vastly superior monitor / keyboard cluster
[09:47] <awilkins> Hence me finding BZR so useful - I can just work offline and tote the data in on a USB key
[09:48] <awilkins> So when they encrypt those keys it will be yet another annoyance.
[09:49] <awilkins> I'd ask if they could supply a license for my to use it at home, but I don't want it on my machine.
[09:50] <awilkins> I don't trust any encryption product you can't read the source for (not that I'm skilled enough to vet it myself, but at least I have the comfort of knowing that hundreds of others have)
[09:50] <AfC> Certainly
[09:51] <awilkins> IMHO they should have found someone who could provide them with a support contract for TrueCrypt
[09:51] <awilkins> I understand their need to have someone to blame, and to pay money to assuage their guilt at not being man enough to take the rap themselves
[09:52] <AfC> awilkins: hah. You should have started a concern to sell such support :)
[09:53] <awilkins> Likewise for archiver - they must have shelled out 15,000 euro, minimum, for a WinRAR license
[09:53] <awilkins> They could have donated , say, 8,000 euro to 7-zip and made them very happy russians
[09:54] <awilkins> The "TrueCrypt support" thing may have legs
[09:54] <awilkins> I wonder if anyone offers it aready
[10:50] <awilkins> Verterok: ping?
[11:56] <quicksilver> Ouch.
[11:56] <quicksilver> bzr: ERROR: exceptions.AttributeError: 'SSHSubprocess' object has no attribute 'get_name'
[11:56] <mwhudson> quicksilver: something to do with paramiko versions
[11:57] <quicksilver> so I was just gathering from google searches.
[11:57] <quicksilver> careless upgrading is the root of all evil.
[11:58] <quicksilver> "Andrew Bennetts" apparently fixed it on the 10th of April, in bzr.
[11:58] <quicksilver> I wonder which bzr version contains the fix.
[12:00] <mwhudson> 1.4 should
[12:00] <quicksilver> hmm. I'm using 1.4. I think.
[12:00] <quicksilver> ah, no, I"m using 1.3
[12:00] <quicksilver> d'oh.
[12:01] <quicksilver> erm. I'm in a mess!
[12:01] <quicksilver> macports thinks I have 1.4 but bzr --version says 1.3
[12:02] <quicksilver> --->  Activating bzr 1.4_0
[12:02] <quicksilver> bzr --version
[12:02] <quicksilver> Bazaar (bzr) 1.3
[12:02] <quicksilver> makes no sense to me :(
[12:02] <mwhudson> that seems broken
[12:05] <quicksilver> I shall force macports to recompile it. If that doesn't work I will go cry on the shoulders of the macports people.
[12:06] <quicksilver> that fixed it.
[12:06] <quicksilver> I obviously broke something in some unpleasant way.
[12:12] <quicksilver> grmargh. Now I broken py25-bz2. Bad python day!
[12:13] <mwhudson> quicksilver: this is all much easier on ubuntu :-)
[12:14]  * awilkins just runs the installer for windows
[12:16] <quicksilver> mwhudson: believe me, I am no stranger to the shortcomings of anything-which-isn't-apt.
[12:17] <quicksilver> mwhudson: I *really* wanted apple to use dpkg for OSX. They even hired a dpkg developer.
[12:17] <mwhudson> quicksilver: parallels is only $50 :)
[12:17]  * mwhudson stops being gratuitously unhelpful
[12:17]  * quicksilver was even a debian developer once. elmo over there did his security call.
[12:49] <joh> Is it possible to edit a committed message?
[12:50] <jamesh> joh: no
[12:50] <jamesh> although you can create a new revision with a different message
[12:51] <jamesh> if you want to change the revision you just committed and you haven't done any other work, then try "bzr uncommit; bzr commit"
[12:51] <bob2> if it was the previous commit, and no one else has merged/pulled it, you can uncommit and re commit
[12:51] <joh> Aw, I forgot to add --fixes
[12:51] <joh> Ok
[12:53] <joh> What if I already pushed the changes to LP?
[12:58] <jamesh> joh: you can "push --overwrite" to update the branch even if you've diverged
[12:58] <jamesh> (which uncommit+commit will do)
[12:58] <joh> jamesh: Great, thanks :-)
[13:38] <muncul> hi ! How can I simply: log to machine ; bind to repository with configuration; than diff checkin etc,  ; and remove .bzr/
[13:39] <muncul> 2. is it possible to have working tree in 2 repos ?
[13:39] <muncul> 1. i mean using /.bzr to version /etc
[13:44] <bob2> dunno about the rest of your question, but you'll want to use etckeeper or something
[13:44] <bob2> or else you won't be versioning file permissions
[13:50] <muncul> i want to have some files from /etc/ in bzr
[13:50] <muncul> but i do want to have repo on central server
[13:50] <muncul> and delete /.bzr after work
[13:50] <muncul> so config history is known only to me
[13:51] <bob2> you'd need to write a little shell script to do that for you
[13:51] <bob2> but lightweight checkout .bzr dirs are quite small
[13:51] <muncul> but when i have repo on server
[13:51] <muncul> and log to machine
[13:51] <muncul> how to make this .bzr binded to central repo
[13:52] <bob2> "bzr bind"
[13:52] <muncul> i tried: bzr: ERROR: Not a branch
[13:53] <muncul> as i said after work i deleted /.bzr last time
[13:53] <bob2> yes, you need to get that back, or not delete it
[13:53] <muncul> so how after delete
[13:53] <muncul> simply branch ?
[13:53] <muncul> and then bind ?
[13:53] <quicksilver> win 29
[13:54] <muncul> but i got conflicts
[13:54] <quicksilver> ! :(
[13:54] <muncul> branch destroys my current /etc/
[13:54] <bob2> don't do that
[13:54] <muncul> bzr is fine but some things seem diffictult to me
[13:54] <bob2> branch to another dir, mv .bzr to /etc
[13:54] <muncul> aaaa
[13:54] <bob2> seriously, not deleting it is a lot less hassle
[13:55] <muncul> but deleting is for privacy
[13:55] <muncul> sometimes needed
[13:55] <muncul> good idea with branching to /tmp/ and moving .bzr
[13:55] <muncul> thx
[13:55] <bob2> "bzr co bzr+ssh://whatever/ /etc" will probably work, too
[13:56] <muncul> checkout doesn't work if i have not .bzr
[13:56] <bob2> wfm
[13:56] <muncul> yes works but creates second etc dir
[14:23] <awilkins> muncul: If you want privacy, would using a lightweight checkout and restricting access to the master branch work for you?
[14:36] <muncul> awilkins> probably shoud if lighwight .bzr works as link only
[15:12] <awilkins> Is jam Mr Meinel?
[15:13] <vila> awilkins: You mean our beloved Mr John Arbash-Meinel ? Then yes ;-)
[15:14] <awilkins> I was hoping to ask him exactly how one uses his "service" plugin
[15:17] <awilkins> Coolio, he dabbles in Judy AND DICOM.
[15:28] <jam> awilkins: hi, yeah that is me
[15:30] <jam> I'll be afk for a bit, but I can discuss it with you later.
[15:30] <jam> awilkins: in short summary, you can just run 'bzr service' in a terminal, and then run one of the clients (there is a C program, and a python one)
[15:31] <jam> there are some caveats, but I can get to those later.
[15:34] <awilkins> jam: I was enquiring because I wanted to use it with the bzr-eclipse plugin
[15:35] <awilkins> So would I just replace the call to bzr.bat with a call to the equivalent "bzr-service.bat" ?
[15:36] <awilkins> (the other approach I'm trying at the moment is binding a "bzr shell" session to a process object and piping things to and from.
[16:03] <jam> awilkins: well, if someone ran "bzr service" then you can talk to the process via sockets
[16:03] <jam> The structure is rather trivial
[16:03] <jam> I might recommend a couple quick fixes
[16:03] <jam> so that it is a bit more robust/secure
[16:03] <jam> it worked for what I wanted at the time (proof of concept)
[16:03] <jam> It shouldn't be too hard to clean up
[16:32] <beuno> is there a hook for the smart server to run "bzr update" after a user pushes to it?
[16:33] <beuno> I'm not sure if the post-push hook will do that
[16:34] <awilkins> post-push uses SSH to run a bzr update local to the server
[16:35] <beuno> hm, that's no good. I need the server to run the update as a different user
[16:35] <beuno> I currently have a cron running updating all repos, but that's getting too expensive
[16:44] <ricardokirkner> hi. I know this might be a little offtopic, but does anyone know what the current status of trac-bzr is? I want to start using it at the company I work, but from what I saw it seems to be little activity right now.
[16:46] <jam> beuno: not on the server side, afaik
[16:47] <jam> beuno: you could certainly hook something like that into our new "post_branch_tip_changed" hook
[16:47] <jam> or whatever it is called
[16:49] <LeoNerd> Anyone here familiar with the 'mmv' command..? Lets you rename multiple files at once based on some pattern. I wonder if a 'bzr mmv' plugin could be based on it?
[16:50] <beuno> jam, the post_branch_tip is on the server side then?
[17:04] <guilhemb> statik: hello! May I phone you for a few minutes, please?
[17:04] <statik> guilhemb: certainly, privmsg
[17:06] <guilhemb> statik: I bet you cannot see my replies in the privmsg
[17:06] <statik> guilhemb: I cannot
[17:06] <guilhemb> ok, maybe my registration for privmsg didn't work, retrying...
[17:08] <guilhemb> statik: but I can see your messages; if you pasted me your phone number in the privmsg I would see it.
[17:08] <statik> guilhemb: ok, will do
[17:33] <nDuff> just curious -- does anyone have knowledge as to how actively paramiko is maintained? I posted a bug report & patch to the ML and bug tracker there ~a week ago, and haven't seen any activity.
[17:47] <vadi2> Somehow loggerhead is messing up. If I click on any of the "changes" links on this page (http://bazaar.launchpad.net/~vadi-mapper-dev/vadi-mapper/main/files), it always gives me changes for the whole trunk, not specific to a file like the tooltip says so.
[17:49] <jam> beuno: post_branch_tip, IIRC, is fired locally and on the server
[17:50] <beuno> jam, great, I'll give it a try, thanks for the tip
[17:50] <jam> nDuff: robey is fairly active, but he is only 1 developer, and can get backlogged with other stuff
[17:51] <jam> nDuff: if it is critical, you could probably ping someone here, as we've worked with him a bit
[18:01] <nDuff> jam, probably not that critical -- I can patch my tree manually for the time being -- but thank you for the update; given the lack of any ACK, I was worrying that paramiko was under abandonment.
[19:14] <pickscrape> Are there any plan afoot for some client-side plugin management UI?
[19:15] <pickscrape> i.e. something that will manage installing/updating/uninstalling plugins.
[19:16] <pickscrape> Yes, your friendly neighborhood package manager could do that, but few plugins appear to be packaged at all.
[19:16] <beuno> pickscrape, yeap, I'm working on that
[19:16] <pickscrape> sweet!
[19:16] <beuno> it's pretty advanced
[19:16] <pickscrape> Is any of it public? I'd like to have a nosey at it... :)
[19:16] <beuno> I'd like to release a preview version of it these next weeks
[19:17] <pickscrape> Yet another killer feature point to bzr :)
[19:17] <beuno> pickscrape, I'll upload one today, and email you the URL if you send me a reminder email  (argentina@gmail.com)
[19:17] <pickscrape> Will do
[19:17] <beuno> the first step is, it tells you if the command you are running is from a plugin you don't have installed
[19:18] <beuno> which is finished
[19:18] <beuno> the installing bit through a checkout is half-way there
[19:18] <beuno> and I got the core bits I needed into 1.4, so that's why it's been stalled for a while
[19:19] <pickscrape> I suppose it would make sense for plugins to maintain a 'current release' branch, so it can always update from the same place.
[19:19] <beuno> that would be the idea  :)
[19:20] <pickscrape> Email sent
[19:20] <pickscrape> Tangent, but is anyone aware of any use-case examples of using the loom plugin?
[19:20] <beuno> pickscrape, great, thanks. I'll upload in a few hours, when I take a while off work
[19:21] <beuno> pickscrape, packaging mostly
[19:21] <beuno> where you have to maintain multiple patches
[19:21] <pickscrape> It seems like one of those fantastic features that could have all sorts of great uses, but I can't imagine any just from the docs.
[19:21] <beuno> I believe that's what drove it's development, but I could be wrong, and lifeless is very unlikely to be awake already
[19:22] <pickscrape> 'Oh, lifeless is a person?
[19:22] <beuno> he's *the* person  :)
[19:22] <pickscrape> Very unfortunate name to have when it gets written next to branch names on launchpad. :)
[19:22] <pickscrape> Had me thinking the branch was dead...
[19:23] <beuno> hahahah
[19:24] <beuno> I promise, he's a person. I've met him
[19:32] <pickscrape> :) I believe you. I genuinely did think 'lifeless' meant the branch hadn't been touched for more than X amount of time though.
[19:33]  * james_w files a bug against lifeless 
[19:33] <pickscrape> :)
[19:33] <pickscrape> Maybe I'm the one who needs a bug ticket raising...
[19:34] <james_w> hi beuno
[19:34] <beuno> hey james_w!  how are you doing?
[19:34] <james_w> great thanks. How are you?
[19:35] <dato> hello beuno, james_w
[19:35] <james_w> hi dato
[19:35] <beuno> james_w, good good, trying to start the week properly, but it doesn't seem to be working  :)
[19:35] <beuno> hey dato!
[19:36] <james_w> start it on tuesday, that always makes it a little easier.
[19:37] <beuno> I'd love to, but I have to convince too many people to follow my lead, and it just feels like it might not work as well...
[20:06] <dato> jelmer: right, bzrtools need one more upload by me. let's see if I can do it tomorrow (together with bzr-gtk, hopefully)
[20:16] <BasicOSX> Using the email plugin is there an entry you can put into location.conf to prevent email notification just for a specific project?
[20:17] <jelmer> dato: yup - thanks!
[20:49] <ricardokirkner> hi. i am trying to access a bzr branch that is exported by apache, but requires authentication and I get the following message: Unable to handle http code 401: expected 200 or 404 for full response
[20:49] <ricardokirkner> I have googled it, but couldn't find any answer
[20:50] <ricardokirkner> do you guys have any idea if auth is working when using http?
[20:50] <beuno> ricardokirkner, 401 seems to me access denied
[20:51] <beuno> are you sure the user/password is correct?
[20:51] <ricardokirkner> beuno, bzr never even asks me for use/pass
[20:55] <beuno> ricardokirkner, it's not interactive
[20:55] <beuno> you have to add it in the url
[20:55] <ricardokirkner> oh. wait... i'll try that
[20:55] <ricardokirkner> :-D
[20:56] <ricardokirkner> now it WAS interactive... after specifying the username, it asked me for the password
[20:56] <ricardokirkner> thank you
[20:56] <beuno> ricardokirkner, yes, it is for passwords
[20:56] <beuno> you're welcome  :)
[20:56] <beuno> I wonder if that can be considered a bug...
[20:57] <beuno> just to annoy vila perhaps
[20:57] <pickscrape> Does seem to violate the principle of least surprise.
[20:58]  * beuno looks to see if it's been reported before
[21:07] <beuno> ricardokirkner, bug #229714
[21:15] <ricardokirkner> beuno, I might even attempt to fix that bug, thank you :-)
[21:16] <beuno> ricardokirkner, that would rock  :)
[21:17] <ricardokirkner> when I get back home from work, I will try
[21:21] <ricardokirkner> I was just wondering.. I know about repositories, and that they allow to reduce duplicate space, but what happens if I start with just one branch and later on I decide I want to use a repo, because I will have many branches... can I just create the repo and then move my branch into it, or what should I do?
[21:21] <dato> create the repo
[21:21] <dato> cd into it
[21:21] <dato> bzr get your branch
[21:33] <ricardokirkner> dato, ok, so in order for the data to be stored in the repo I just re-checkout my branch, right? sounds easy enough. thanks
[21:34] <dato> yep
[21:36] <ricardokirkner> another newbie question (I am really getting into this :-)). when I have created a repository with branches in it. is there a simple way to checkout the full repository? when I point bzr to the url of the repo, I get a message about it not being a branch (which is quite correct)
[21:36] <mwhudson> no, not really
[21:37] <mwhudson> there is a 'multi-pull' command in bzrtools, which is like one tenth of what you're asking for
[21:37] <beuno> sounds like nested branches
[21:37]  * beuno stares at LarstiQ 
[21:37] <dato> beuno: not really, I think
[21:38] <beuno> dato, well, partially at least
[21:38] <ricardokirkner> beuno, not really. I just mean the whole repo, but the branches within are just related by belonging to the same project
[21:38] <beuno> enough to other LarstiQ with it
[21:38] <beuno> right, it should share some code with nested branches though
[21:40] <dato> I don't think so...
[21:41] <beuno> hm, then I'll get back to work  :)
[23:42] <pickscrape> I just did update on a checkout that contained some commits I'd made using --local, and they've vanished
[23:43] <pickscrape> I can see the commit using the heads plugin. Any tips on how I can get it back?
[23:43] <pickscrape> Would the rebase plugin be of use here?
[23:44] <james_w> pickscrape: are they listed at the end of "bzr status"?
[23:44] <pickscrape> Oh, yes they are actually.
[23:45] <pickscrape> As pending merges, and many of the files in the repo are marked as modified too
[23:45] <james_w> yeah, they get converted in to "pending merges", if you resolve any conflicts and commit you will see them in the output of "bzr log -r -1"
[23:45] <pickscrape> commit with --local again? (if I don't want to go upstream yet)
[23:45] <james_w> that will work.
[23:46] <james_w> (I hope)
[23:46] <pickscrape> :)
[23:47] <pickscrape> Yep, that worked, though I now have one revision with the three commits as parents of it. Presumably though this is what would have happened when I wanted these revisions to go upstream anyway, right?
[23:48] <pickscrape> Useful bit of experience this... Would update be the correct command when you do want to sync your local commits with upstream?
[23:48] <pickscrape> i.e. update, then commit without --local
[23:50] <pickscrape> Ah, doing update again I now see the completely clear message it gives at the end about local commits being pending merges.
[23:50] <pickscrape> I missed that before because I'd done the update through olive (messing about)
[23:51] <james_w> pickscrape: yes, if both upstream and you were moving forward (committing) then you would need to do a merge at some point to send your work upstream
[23:51] <pickscrape> Yes. In this case I'm the only one doing any committing.
[23:51] <james_w> this can either be an explicit merge with "bzr merge", or an implicit one with "bzr update"
[23:51] <james_w> but upstream are committing on their branch?
[23:52] <james_w> or are you upstream as well?
[23:52] <pickscrape> I'm upstream as well. I'm experimenting with the centralised workflow.
[23:52] <pickscrape> I actually think there's as little room for improvement here. My local checkout was the same as upstream with a few commits extra.
[23:53] <pickscrape> So I think in that case, update could have left things as they were.
[23:53] <pickscrape> Instead it's forced me to merge, when I might not have wanted to at this point.
[23:53] <james_w> ah, my instinct would have been that it would have done exactly that
[23:54] <pickscrape> merge, or leave alone?
[23:54] <james_w> leave it alone
[23:54] <pickscrape> Yes, I'd expected it to be a noop.
[23:54] <jml> what's the recommended bzr-svn to use.
[23:55] <james_w> hi jml
[23:56] <james_w> pickscrape: I see now that it does always merge
[23:56] <jml> james_w: hi.
[23:56] <jml> james_w: it's been a while :)
[23:56] <james_w> jml: I think 0.4.10, or 0.4.9 failing that
[23:56] <james_w> are you in Prague next week?
[23:56] <jml> I am.
[23:56] <james_w> great!
[23:57] <igc> morning all
[23:57] <james_w> I've got some questions for you, come prepared :-)
[23:57] <james_w> hi igc
[23:57] <jml> james_w: actually, if you ask them now, perhaps via email, I might be even more prepared.
[23:57] <pickscrape> james_w: Yes, I just tried it with a trivial example
[23:58] <james_w> jml: that's true, I don't know exactly what they are yet, so I'll write you an email later explaining what I'm working on if that's ok?
[23:58] <jml> james_w: that'd be great.
[23:59] <jml> Last week, I made my first working .deb in preparation for UDS :)
[23:59] <james_w> pickscrape: so, you could say that "update" means, give me upstream's branch with anything I have locally being working tree modifications/pending merges, which gives you this behaviour.