[01:13] <poolie> mgz, heaven help us when we get to 7 digits
[01:14] <poolie> maybe we can have optional punctuation: 184-2223
[01:14] <poolie> biab
[06:32] <arnetheduck> hi, just noticed you forgot to blame me for the log matching in http://doc.bazaar.canonical.com/latest/en/release-notes/bzr-2.5.html#bzr-2-5b1 =)
[07:45] <vila> arnetheduck: the way devs ususally take credit is to add a news entry in doc/en/release-notes/bzr-x.y.txt, unfortunately no reviewer reminded/explained that to you :-/
[07:46] <vila> arnetheduck: it's not too late to either send an email to the mailing list with the entry you want or file a merge proposal (that will certainly be approved ;)
[07:47] <vila> arnetheduck: sorry about the confusion there, I really appreciate this feature (I even encountered a case where I suggest to use it only to be reminded that it was available only in 2.5 ;)
[07:51] <jelmer> grar
[07:51]  * jelmer does the mumble configuration dance
[08:00] <Riddell> ping vila
[08:00] <Riddell> no jam I guess
[08:00] <vila> jelmer, Riddell, jam: poolie sent an email saying he will be off
[08:00] <vila> Riddell: yeah :)
[08:01] <Riddell> vila: that's no excuse for you to skive off!
[08:01] <vila> hehe, I'm not !!
[08:34] <vila> jelmer: http://webnumbr.com/ubuntu-package-import-failures.from%282011-08-29%29
[14:00] <zyga> ho
[14:00] <zyga> hi
[14:01] <zyga> how is bzrlib expected to be initialized on python 2.4 where there is no with support?
[14:12] <vila> zyga: bzr-2.3 is the last stable version supporting python-2.4
[14:12] <vila> zyga: 'with' is not used there
[14:12] <zyga> vila, so just bzrlib.initialize() and "go" ?
[14:13] <vila> zyga: that's what the doc string says, yes
[16:21] <Guest95861> Hey all — I think this is probably a really obvious question, but I just cannot seem to find an answer. I have a Launchpad project that I was doing some work with, that I then decided to update my local code from upstream. I performed a bzr merge, but now that left me with uncommitted changes locally (not my changes, they are the changes from upstream)
[16:21] <Guest95861> What did I do wrong?
[16:22] <Guest95861> Performing additional bzr merges complains about the uncommitted changes
[16:22] <Guest95861> The actual thing I want to accomplish is to have my repo look like the upstream repo
[16:44] <jelmer> Guest95861: hi
[16:45] <jelmer> Guest95861: you didn't do anything wrong - you have to commit the merge
[17:10] <Guest95861> Oh! Thank you!
[17:10] <Guest95861> I thought committing it might make my local copy go out of sync
[20:05] <supton> is `bzr pull --overwrite -rOLDER_REVSION_THAN_CURRENT` really as dangerous as it looks?
[20:05] <supton> as in, it permanently stomps on all local commits
[20:06] <supton> ...that are not available from the pull repos
[20:06] <AuroraBorealis> if all else fails, just make a backup before you do anything
[20:06] <jelmer> hi supton
[20:06] <supton> hi jelmer
[20:06] <jelmer> supton, it removes the reference to those revisions from the local branch
[20:07] <jelmer> supton, but the revisions are still available from the repository, you should be able to get those revisions back from the repository by using "bzr heads"
[20:09] <supton> jelmer: so say I checkout... `bzr branch -r123 lp:~seanupton/+junk/something` and then make a local commit to r124 in that branch (but never push anywhere), then my automated build tool does a `bzr pull --overwrite -r123` in that branch.  What happens to local r124?
[20:14] <jelmer> supton, the branch gets updated to point at r123
[20:14] <jelmer> but the contents of r124 are still in the repository
[20:15] <supton> FWIW, I am adding revision-pinning support to the bzr support of an automated build tool (mr.developer, which is an extension for zc.buildout). https://github.com/seanupton/mr.developer/commit/47f83fa4d59d5f06373c7cb2f91e6d00bf07c741#L1R63
[20:16] <jelmer> supton, ah, cool
[20:19] <jelmer> supton, it's a pity you're calling out to bzr rather than importing bzrlib
[20:20] <supton> jelmer: does bzr heads command exist in 2.4.0?
[20:20] <jelmer> supton, yes, but it's a part of the bzrtools plugin
[20:20] <supton> jelmer: I'm assuming that the goal of upstream folks for mr.developer is few library deps.
[20:21] <supton> jelmer: ah, okay, I'll install bzrtools
[20:25] <jelmer> supton: that seems silly, given installing bzr will pull in that library anyway
[20:25] <supton> jelmer: yeah, but the typical assumption among a lot of folks using buildout is that they are not using the system python
[20:26] <supton> which means they don't want to install bzrlib in their buildout or for the python running their apps when it is installed (sufficiently, as far as they care) in the system python's site-packages
[20:27] <supton> so folks like me are using macports or apt to get bzr, bzrtools, bzrlib, etc and then only lightly automating around them from python app deployments that are not using the system python at all.
[22:43] <poolie> hi jelmer, all
[22:48] <jelmer> g'morning poolie
[22:48] <jelmer> I hope you're feeling better
[23:32] <poolie> a bit
[23:32] <poolie> well, mostly better
[23:32] <poolie> might go back to bed in a bit though
[23:32] <poolie> how are you?
[23:45] <jelmer_> alright, doing some more foreign branch hacking before sleep