[01:17] <maxb> vila: Does bzr-landing-dependencies have a bzr branch?
[02:17] <maxb> So are we on for 2.2 today?
[02:20] <fullermd> Man, you're behind.  I've had 2.2 for months   ;)
[02:32] <GungaDin> Hi
[02:34] <thumper> hi
[02:34] <thumper> didn't someone start a gitorious fork using bzr?
[02:34] <thumper> anyone know the status of it?
[02:41] <GungaDin> Is it possible to generate a diff/patch by simulating a merge ?
[02:44] <spiv> GungaDin: 'bzr merge --preview'
[02:46] <GungaDin> can that be used with patch?
[02:47] <thumper> GungaDin: I believe so
[02:47] <beuno> or bzr send?
[02:47] <beuno> hai thumper!
[02:48] <thumper> hi beuno
[02:49] <thumper> GungaDin: what are you trying to achieve?
[02:51] <GungaDin> to patch the changes of a merge.
[02:51] <GungaDin> I don't want the history tracked. just need to patch.
[02:52] <thumper> GungaDin: you can do that with bzr
[02:52] <thumper> if you merge the branch
[02:52] <thumper> then I think you do bzr revert .
[02:52] <thumper> don't forget the dot
[02:52] <thumper> and I think that merges the content without the history
[02:53] <thumper> but I'd like lifeless or spiv to check that
[02:53] <spiv> bzr revert --forget-merges
[02:53] <spiv> thumper: 'bzr revert .' is the opposite :)
[02:53] <thumper> good thing I checked then :)
[02:54] <thumper> spiv: so with --forget-merges it keeps the file changes?
[02:54] <spiv> GungaDin: So do 'bzr merge' followed by 'bzr revert --forget-merges'
[02:54] <spiv> thumper: yes
[02:54] <thumper> cool
[02:54] <thumper> thanks
[02:56] <GungaDin> cool. thx
[07:48] <vila> hi all !
[07:49] <Peng> Good morning. :)
[07:49] <mgz> morning vila.
[07:50] <vila> :)
[07:55] <vila> mgz: do you have a way to reproduce bug #681047 ?
[07:55] <mgz> nope, only seen it on babune, as I don't have paramiko installed locally
[07:56] <vila> mgz: hmm. Do you agree that get_bytes()/get() may be a cause ?
[07:57] <mgz> looked like a good thing to fix, but I'd be suprised if it were the cause
[07:57] <vila> mgz: taking into account that paramiko do some internals sleep()
[07:57] <mgz> I'm pretty sure that refcounting means the file is closed at the end of that statement
[07:58] <mgz> http://babune.ladeuil.net:24842/job/selftest-windows/242/ <- last run has one of the sftp failures
[07:58] <mgz> ...also has an lsprof thing I don't think I seen before
[07:58] <mgz> http://babune.ladeuil.net:24842/job/selftest-windows/242/testReport/junit/bzrlib.tests.test_lsprof/TestStatsSave/test_stats_save_to_pickle/ <- any ideas on this?
[08:01] <vila> EOF during a file read... sounds a bit like the bucket I put many random failures into: vbox having trouble /bug with fs updates/caching >-/
[08:01] <vila> which is so vague I don't dare mentioning it usually...
[08:03] <mgz> was guessing something like that
[08:05] <vila> The scary thing with this scenario is that it implies a very stealth bug with a very low occurrence rate which more or less means it will never be fixed :(
[08:06] <vila> On the other hand, the fact that the pattern is common to so many various OSes can hardly be caused by bzr itself (since it doesn't occur on real hardware...)
[08:16] <vila> mgz: by the way, it's nice to have clearer failures in the other cases ;)
[10:26] <vila> maxb: I have only a local branch for bzr-landing-dependencies so far, that's bad, but I don't know where to put it, defining an lp project for it sounds too heavy-weight, keeping a local branch too light, ideas welcome
[10:37] <spiv> vila: +junk until you decide?
[10:40] <vila> right
[10:40] <vila> done: lp:~vila/+junk/bzr-landing-dependencies
[10:41] <vila> thanks to bzr for reminding at first push, I don't have to note it anywhere...
[10:43] <maxb> vila: you should be able to push it to lp:~bzr/ubuntu/hardy/bzr-landing-dependencies/bzr-ppa
[10:44] <vila> maxb: brilliant
[10:44] <vila> done
[10:45] <vila> maxb: where is this defined ?
[10:46] <vila> I mean, what are the rules there (especially the 'bzr-ppa' part) ?
[10:47] <maxb> the bzr-ppa part is nothing more than convention established by me
[10:49] <vila> lol :) Best doc ever ! Ask and you should receive an answer :D
[10:49] <maxb> there was an email thread a while back where I proposed and then did a rename of all the extant ppa packaging branches
[10:50] <vila> ok, then, what is allowed under lp:~bzr/ubuntu/hardy/ (this is <user>/<distro>/<series> right ?) ?
[10:50] <maxb> the rest of the 5-component name is launchpad's schema for identifying source package branches
[10:51] <maxb> so, person/distro/series/package
[10:51] <vila> even if bzr-landing-dependencies is not  (yet?) an "blessed" package ?
[10:52] <maxb> handily using the accidental? feature that even PPA package names work there
[10:53] <vila> ooooh, so it's not that arbitrary then, it should catch tyops :D
[14:03] <DaffyDuck_`> If I use a shared repo (init-repo), and create a bunch of branches within it. Is it safe to remove branches from the shared repository if they turn out to be dead-ends, or are the repostitory files and branch files weaved together?
[14:05] <Peng> DaffyDuck_`: Nuke branches to your heart's content. All of the important data is in the shared repo itself. Note that this means the revisions unique to that branch won't be deleted.
[14:06] <Peng> (Unless something has changed significantly recently...)
[14:09] <DaffyDuck_`> Peng: Thanks. I trust that if it has had that behavior, it still does. :)
[14:11] <Peng> DaffyDuck_`: Check if something has a .bzr/repository to be sure.
[14:13] <DaffyDuck_`> Yeah; my plan was to run "bzr info" to see if it mentions being a part of a repository before nuking anything.
[14:29] <Peng> Yeah, that works too. :P
[15:28] <mvo> hey, could someone help me please with a rather odd error message? I work on "bzr+ssh://bazaar.launchpad.net/%2Bbranch/vmbuilder/" (lp:vmbuilder) and do "bzr merge lp:~mvo/vmbuilder/add-natty". now it tells me:
[15:28] <mvo> bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.12/".
[15:29] <mvo> where does it get this from? I'm pretty sure that lp:~mvo/vmbuilder/add-natty is a branch of lp:vmbuilder
[15:29] <jelmer> mvo: Hi
[15:29] <mvo> hey jelmer
[15:29] <jelmer> mvo: I suspect lp:~mvo/vmbuilder/add-natty was originally stacked on that other branch but the other branch has been renamed
[15:29] <jelmer> or perhaps removed
[15:29] <mvo> should I just apply the diff or is there a better workaround?
[15:31] <jelmer> mvo: do you know what happened to the original 0.12 branch?
[15:31] <mvo> I have no idea :(
[15:31] <jelmer> If it's still around under another name, or if it was merged into another branch then you should be able to fix the stacked-on location
[15:31] <jelmer> You can see the reference to the 0.12 branch here: http://bazaar.launchpad.net/~mvo/vmbuilder/add-natty/.bzr/branch/branch.conf
[15:32] <mvo> can I just mug around in that file to point to a different one?
[15:32] <jelmer> mvo: yep
[15:32]  * mvo puts his cowboy hat on and tries it
[15:33] <jelmer> I thought launchpad prevented removing branches that had other branches stacked on them, but apparently there isn't complete coverage.
[15:35] <mvo> this is rather odd - I just pushed my local branch to lp as add-natty2 and it said that it reated it as a stacked branch on top of 0.12 as well. but this one I can merge to trunk
[15:35] <mvo> worth a bugreport?
[15:35] <jelmer> mvo: Yeah, I think so
[15:42] <mvo> bug #681431
[15:43] <mvo> probably needs adjustment, maybe its code-hosting instead of bzr? or both?
[15:43] <mvo> thanks for your help, I was able to workaround it now
[15:46] <lvh> Hey. I'd like to integrate Roundup with bzr. I'm hosting bzr on a server with bzr+ssh. Closing/referencing tickets seems easy, since those are commit hooks. I'm wondering about *assigning* tickets: I'd like to assign them when someone branches off.
[15:46] <lvh> If I understand correctly there's no hook for that at the moment.
[15:47] <lvh> (And unlike in SVN a branch doesn't imply a commit. I like that, but it makes this somewhat unfortunate.)
[15:47] <lvh> Perhaps a push hook? Does the hook know who committed?
[15:48] <lvh> I'm looking at http://wiki.bazaar.canonical.com/BzrHooks, it mentions bzr 1.0 hooks. Is that hopelessly outdated?
[15:57] <mvo> hm, hm, there is  https://launchpad.net/vmbuilder/0.12 and claims the 0.12 series points to lp:vmbuilder
[16:02] <maxb> mvo: Note the difference between ~ubuntu-virt/vmbuilder/0.12 and ~vmbuilder-dev/vmbuilder/0.12
[16:03] <mvo> ohhhh
[16:03] <maxb> Do you need to rescue an existing branch, or have you completely worked around it by repushing a local copy?
[16:04] <mvo> for the initial one I worked around by pushing my local copy, but I would like to e.g. branch the "packaging" branch which is not possible now
[16:04] <mvo> currently
[16:05] <maxb> mvo: Do you have write access to the problem branch?
[16:06] <jelmer> lvh: Yeah, I don't think the wiki has been updated - try "bzr help hooks" ?
[16:06] <mvo> not the packaging one :/ to trunk though
[16:06] <lvh> jelmer: Ooooooh. Nice.
[16:06] <mvo> the one I wanted to work on next is lp~soren/vmbuilder/packaging
[16:06] <lvh> jelmer: Thanks
[16:06] <mvo> but that is not owned by me
[16:07] <maxb> mvo: hmm. In that case we need a losa or someone who does. Or, in a pinch, you can copy the branch content locally and fix it up on your local machine
[16:07] <soren> mvo: What do you want to do to it?
[16:08] <mvo> soren: make it work again (i.e. make it possible to branch it again). see https://bugs.launchpad.net/launchpad-code/+bug/681431
[16:08] <mvo> soren: it appears its unhappy because its stacked on location changed
[16:08] <soren> mvo: I'm not even sure I have a local checkout of it.
[16:09] <soren> mvo: Let me know if I can help.
[16:09] <maxb> soren: Could you download a script I wrote for this purpose? http://j.maxb.eu/~maxb/bzr-set-stacked-url
[16:09] <mvo> oh, nice
[16:10] <lvh> jelmer: None of these hooks appear to know which user did it though
[16:10] <mvo> soren: once I have that branch I will update it to include the current packaging and push it as ~vmbuilder-dev so that its in sync again (I guess you don't mind :)
[16:10] <maxb> Then you can run bzr-set-stacked-url lp:~soren/vmbuilder/packaging lp:~vmbuilder-dev/vmbuilder/0.12
[16:10] <soren> I'm cooking dinner right now, actually.
[16:11] <jelmer> lvh: you can check who committed the revision that was pushed?
[16:11] <soren> mvo: Can you ping me about it this evening or tomorrow? I'd be happy to help get this sorted out.
[16:11] <lvh> jelmer: I suppose I could use bzr's notion of who did it and not ssh's notion of who did it and it'd even be more correct
[16:11] <lvh> jelmer: Right
[16:11] <maxb> soren, mvo: I'll sort it via scping the branch and push it to lp:~maxb/vmbuilder/packaging
[16:11] <mvo> soren: will do, maybe I find find a LOSA in the meatime to fix it up, but if not, I will ping you
[16:11] <mvo> maxb: cool! many thanks .)
[16:11] <soren> mvo: Lovely.
[16:12] <lvh> jelmer: post pull and push are client-only, so either I need cooperative clients or something else
[16:12] <jelmer> lvh: you can't really rely on anything but the client as bzr supports "dumb" push
[16:13] <lvh> jelmer: I'm working under the assumption everyone does everything over bzr+ssh
[16:13] <maxb> mvo: pushed
[16:13] <lvh> post-branch-init looks promising
[16:14]  * mvo hugs maxb
[16:15] <lvh> jelmer: If I understand correctly http://people.canonical.com/~mwh/bzrlibapi/bzrlib.branch.BranchInitHookParams.html isn't linkable to the bzr concept of a person, because there are no commits made. Does that sound right?
[16:17] <jelmer> lvh: yeah
[16:18] <lvh> Hm, unfortunate, but I guess I'll live :-) Thanks jelmer :-)
[17:04] <maxb> Hrm. PQM seems to only be accessible under pqm.bazaar-vcs.org, there appears to be no pqm.bazaar.canonical.com
[17:05] <maxb> This doesn't feel like the sort of thing to file on Launchpad. Maybe a Canonicalite could log a suggestion or RT for the Canonical sysadmins?
[17:07] <vila> maxb: why ?
[17:07] <maxb> Consistency. AFAIK every other bazaar resource has moved off bazaar-vcs.org
[17:08] <vila> Well, the other ones are targeted at users, whereas pqm is only targeted at committers... which I strongly suspect won't upgrade their configs :D
[17:09] <vila> ..not mentioning the docs...
[17:10] <vila> maxb: and since there are plans to migrate from pqm to tarmac, I'd rather keep the energy focused on that instead
[17:10] <maxb> ah, ok
[17:12] <vila> maxb: I'm about to EOD, but I plan to look at what needs to be done for the MRE regarding 2.2.2 (or the SRU otherwise) first thing tomorrow, I may ask you silly questions then, be prepared ;D
[17:13] <maxb> vila: We pop it in the PPA, say, "look, it passes, please rubberstamp that this SRU has met our MRE conditions, thanks"
[17:13] <vila> maxb: you're just great :D
[17:13] <maxb> Then we validate the package in maverick-proposed did actually build correctly, and say "it works, please promote to maverick-updates"
[17:15] <vila> right, so I need to setup the right branches on my side and document the above
[17:16] <vila> This sounds like a good summary, but 'validate .. in maverick-proposed' is still a bit obscure to me, ha, no, we do nothing more for that than pointing to the right package branch ?
[17:16] <vila> i.e. let me try
[17:17] <vila> lp:~bzr/ubuntu/maverick/bzr/bzr-ppa ?
[17:17] <vila> or bzr-proposed ?
[17:17] <vila> nah, bzr-ppa when available right ?
[17:27] <maxb> yes.... but no :-)
[17:27] <maxb> We probably want to prepare the SRU on top of the existing ubuntu packaging branch
[17:27] <maxb> And then just happen to commit equivalent changes onto the PPA branch
[17:28] <maxb> Also, we need to assess the list of bugs fixed by this SRU to prepare an appropriate debian/changelog entry
[17:29] <maxb> Also I've been refining the debian/rules invocations to run the testsuite in the maverick bzr-ppa package, so some of that needs to be ported onto the ubuntu branch
[17:29] <maxb> I'd can do that tonight if you like
[17:40] <maxb> vila: ^
[17:50] <vila> maxb: whatever works for you, I'd be happy to only look as well as being your hands there
[17:51] <vila> maxb: I'm off now, but I will read the log
[17:51] <maxb> ok
[19:48] <ccxCZ> did I misunderstand, or is bzr merge --interactive broken when it does not record the commit as merge?
[19:48] <ccxCZ> it's plain commit in my history
[19:52] <maxb> ccxCZ: I could believe that it might be deliberate
[19:53] <maxb> Recorded merges are supposed to denote complete merges of that line of history, whereas if you omit chunks, that's not really the case
[19:53] <ccxCZ> well certainly it's not documented in help and now my history messed up :/
[19:53]  * maxb reads the source code
[19:55] <maxb> It rather does look like this is the case
[19:56] <ccxCZ> ok I'll remerge that
[19:56] <ccxCZ> but it's kind of nasty, since one might want to cherrypick
[20:02] <maxb> ccxCZ: Well that's rather the point. An interactive merge by definition is a cherrypick of sorts, and cherrypicks are never recorded as full merges.
[20:15] <Ng> does bzr use launchpad's edge server to decode lp:foo locations?
[20:15] <Ng> hmm, I mean "is it hard coded to do that", because the machine I'm using clearly is trying to use edge for that
[20:20] <maxb> Ng: I believe it has done in some versions of bzr. Not sure if it still does, though
[20:20] <elmo> yeah, it's known and known as a bug
[20:21] <elmo> also not sure if/when it's been fixed
[20:21]  * maxb cries at the mess of parallel imports for bzr UDD packaging
[20:22] <lifeless> Ng: https://bugs.launchpad.net/bzr/+bug/583667
[20:23] <Ng> ta all
[20:34] <lifeless> Ng: what version do you have?
[20:34] <Ng> lifeless: 2.0.4
[20:35] <lifeless> I suspect that still uses edge for lp:
[20:47] <maxb> Ng: This changed in 2.2. Might be worth upgrading, for the steady stream of bugfixes since then
[20:47] <elmo> the bzr --whoami thing is blocking us
[20:48] <elmo> or, at least, that's why we're still on 2.0.4
[20:48] <maxb> What is the --whoami thing?
[20:48] <elmo> maxb: https://bugs.launchpad.net/bzr/+bug/616878
[20:49] <maxb> elmo: Is your /etc-in-bzr via etckeeper?
[20:50] <elmo> maxb: our setup pre-dates etckeeper, but it's the same idea
[21:26] <maxb> jelmer: for the 2.2.2 maverick SRU, shall we just leave the testsuite not using the compiled extensions, since we have not settled how we want to fix that, do you think?
[21:30] <jelmer> maxb: Yeah, I think that's a good point. Let's not make any unnecessary last minute changes.
[21:43] <maxb> jelmer: Right. I am planning to put the "run bundled plugin tests" change in, though, since I've already run that through the PPA to validate it
[22:26] <maxb> Rather madly, I think bug 659590 is actually the most important fix in 2.2.2 for Ubuntu
[22:30] <maxb> Hrm.
[22:30] <maxb> According to the SRU process we need to release 2.3b4 and get it into natty before we can SRU 2.2.2
[22:58] <maxb> AAAAAAAAAARRRRRGHH
[22:58] <maxb> Our MicroReleaseException is broken
[22:59] <maxb> We cannot run the testsuite during package build, because bzr is in main, but python-testtools is in universe.
[23:22] <jelmer> maxb: :-((
[23:22] <jelmer> maxb: We should really try to get python-testtools into main.
[23:22] <jelmer> maxb: But I guess that's not something we could do for this SRU..
[23:23] <maxb> I think I'm about ready to throw my hands up in horror and say "SRU? What's that? We have a lovely ~bzr PPA for you to use!"
[23:25] <lifeless> (
[23:25] <lifeless> :(
[23:42] <maxb> Speaking of which, uploadded 2.2.2 to bzr/proposed now