[00:47] <lifeless> is this a regression:
[00:47] <lifeless> :!bzr pull :push
[00:47] <lifeless> bzr: ERROR: Unsupported protocol for url "lp:~lifeless/launchpad/bug-722956"
[00:58] <spiv> lifeless: I'm not sure, but it's certainly not ideal.
[00:59] <spiv> lifeless: not a regression based on quick experimentation
[00:59] <lifeless> spiv: k. do you want a bug files?
[01:00] <poolie> there may be one, but if there isn't please do
[01:16] <lifeless> poolie: I no longer know the bzr bugs like the back of my hand :)
[01:18] <lifeless> poolie: I've filed bug 728162, I wasn't sure how imprtant to make it, and have left it untriaged as a result
[05:47] <stewart> hi! I'm having issues using fast-export to do a fast-import into git. I'm getting an error from the git fast-import about a path not being in branch.
[05:47] <stewart> http://paste.drizzle.org/show/418/ and http://paste.drizzle.org/show/419/ are relevant
[05:48] <stewart> (i'm only trying the import to run gitdm on it... instead of extending bzr stats, at least initially)
[05:48] <poolie> hi
[05:49] <stewart> poolie, hi!
[05:54] <poolie> sorry that doesn't ring any bells
[05:55] <poolie> i would probably dig into the fastexport stream to work out whether the name was in fact written already
[05:55] <stewart> poolie, hrm. darn.
[05:55] <stewart> poolie, i'll try doing a bzr fast-import :)
[06:39] <spiv> Hmm, is it just me, or is per_branch.test_bound_sftp always skipping every test?
[06:47] <jam> spiv: yes, I saw that a while ago, and I think I opened a bug
[06:52] <stewart> poolie, the first mention of that path is a "M 644 inline storage/innobase/handler/handler0alter.cc" line... which IIRC means the same as create new file, right?
[07:12] <poolie> i think so
[07:12] <poolie> hi spiv, jam
[07:13] <stewart> trying new git version, seeing if it's fixed there :)
[07:43] <maxb> spiv: I'm sorry to report that the bzr-loom testsuite run in the daily PPA is still having five tests failing with NoSuchRevision exceptions after your branch has landed
[07:44] <maxb> although...perhaps thats because the version of bzr itself wasn't new enough
[07:44]  * maxb hits some rebuild buttons
[07:46] <spiv> maxb: yeah, that's probably what's up
[09:20] <maxb> Hurrah! The daily PPA is now *all green*
[09:25] <lifeless> \o/
[10:25] <catphish> does bazaar support a 'receive' hook?
[10:39] <maxb> catphish: What is a 'receive' hook?
[10:41] <catphish> when a client pushes to a server, a 'receive' hook would be executed on the server side
[10:41] <catphish> similar to pull i suppose, but initiated by an external host
[10:50] <maxb> That's a git-ish way to describe it :-)
[10:50] <catphish> i'm a git user :)
[10:50] <maxb> There's a post_change_branch_tip hook
[10:50] <catphish> that is what i need :)
[10:50] <maxb> What do you want to do with the hook?
[10:51] <catphish> when someone pushes to my branch i want to know what commits were pushed
[10:51] <maxb> right
[10:51] <maxb> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/hooks-help.html#post-change-branch-tip
[10:52] <catphish> that seems ideal, thanks
[10:52] <catphish> is there any documentation about what params it passes?
[10:52] <maxb> yes.... at that link
[10:52] <maxb> post_change_branch_tip is called with a bzrlib.branch.ChangeBranchTipParams
[10:53] <catphish> oh yeah
[10:53] <catphish> sorry i'm not actually a python developer but hopefully i can push that out to a shell script easily enough
[10:54] <catphish> it has all the parameters i need in that object
[11:10] <lool> james_w: Hey; how do bzr fixes propagate to UDD?  I see bzr was fixed in tip to fix the flash-kernel bug; do we then need a bzr package upload in natty and some action on package-import.ubuntu.com before this gets picked up?  do I need to ask for flash-kernel to be tried again?
[11:16] <spiv> lool: the bzr on package-import.ubuntu.com needs to be updated
[11:16] <lool> spiv: is this a manually installed one, or a .deb from Ubuntu?
[11:17] <spiv> It's a deb, packaged by the admins I think
[11:18] <spiv> Probably an RT asking for it to be updated to tip of lp:bzr/2.3 would be the next step, although perhaps having a tarball release would help, I'm not sure.
[11:19] <spiv> I think it's based on a deb for hardy in one of our PPAs.
[12:42] <jam> jelmer: just a poke that your converter script should be ready to land
[12:43] <jam> spiv: isn't it ~midnight in sydney?
[12:43] <jam> but hi, nonetheless
[12:43] <jelmer> hi John
[12:43] <jelmer> jam: Which converter script?
[12:44] <jam> https://code.launchpad.net/~jelmer/bzr/converter/+merge/51993
[12:44] <jam> Ah, I see it says sent-to-pqm
[12:44] <jelmer> jam: It's already merged :)
[12:44] <jam> did you have some problems recently with that? I thought I saw a patch from you that got about 4 submissions
[12:44] <jam> jelmer: guess it is just lag on LP's part, then.
[12:44] <jam> or, lag on *my* part refreshing the page :)
[12:44] <jelmer> heh :)
[12:45] <jam> would be nice to have Queued to take things out of Approve Ready to Land
[12:45] <jelmer> jam: Are you seeing this in hydrazine?
[12:45] <jelmer> there's a bug in launchpadlib that makes it connect to staging rather than production
[12:45] <jam> jelmer: no, on +activereviews
[12:45] <jelmer> and staging's data is behind on production
[12:45] <jelmer> oh
[12:46] <jelmer> jam: I had some problems with my mail server a week or so ago, so some of my PQM submissions were being blackholed
[12:46] <jam> I haven't had any particular problems with feed-pqm and this
[12:46] <jam> ah
[12:46] <jam> fun
[14:59] <catphish> i seem to be having an odd problem with locks
[14:59] <catphish> when i push i get "Could not acquire lock"
[15:00] <catphish> it seems to be able to get a log but can never release it
[15:00] <catphish> "bzr break-lock" returns bzr: ERROR: No such file: '/data/repos2/19/04af0f-525c-c55a-ec7e-0b7b801b8819/master/.bzr/branch/lock/held'
[15:00] <catphish> which is simply not true
[15:05] <catphish> ah - it only happens on bzr+https
[15:05] <catphish> not plain http
[15:05] <catphish> how odd
[15:06] <catphish> probably another client bug in 2.1.1
[15:38] <sidnei> is there a command in bzr that updates either a bound or unbound branch without bothering about which kind it is?
[15:46] <maxb> um, define update?
[15:46] <maxb> update on an unbound branch means make the working tree version match the branch version
[15:47] <maxb> update on a bound branch involves making the working tree version match the (master) branch version, possibly synchronizing the local mirror of the branch data
[15:48] <maxb> What about 'bzr pull' ? Does that do what you need?
[16:20] <maxb> jam: Hi. Question about loggerhead - what are your plans for the evicted "experimental" branch? Are you going to bring all that lot in in a big merge at some point, or would it be useful to selectively propose merging of some of the feature branches that landed on experimental whilst it was trunk, to the new trunk?
[16:21] <jam> maxb: if you have bits you can selectively propose, that would be great.
[16:21] <jam> I don't really know how to split it apart at this point
[16:22] <maxb> In that case, I think I will fire up qlog, and try to extract some merged feature branches for re-merging
[21:45] <poolie> hello all
[21:59] <jelmer> g'morning poolie
[22:00] <poolie> hi there jelmer, how are you?
[22:00] <jelmer> Doing all right, had a productive day :)
[22:01] <jelmer> sorry I wasn't more awake during the meeting yesterday
[22:02] <jelmer> How's your morning?
[22:10] <poolie> np
[22:10] <poolie> pretty good
[22:10] <poolie> stephane is learning to scuba dive during her holiday, so i dropped her off at a little cove on sydney harbour this morning
[22:10] <poolie> that's a nice way to start the day
[22:11] <poolie> i'd like to actually write some code today after just doing mail and admin and sysadmin stuff yesterday