[01:17] vila: Does bzr-landing-dependencies have a bzr branch? [02:17] So are we on for 2.2 today? [02:20] Man, you're behind. I've had 2.2 for months ;) [02:32] Hi [02:34] hi [02:34] didn't someone start a gitorious fork using bzr? [02:34] anyone know the status of it? [02:41] Is it possible to generate a diff/patch by simulating a merge ? [02:44] GungaDin: 'bzr merge --preview' [02:46] can that be used with patch? [02:47] GungaDin: I believe so [02:47] or bzr send? [02:47] hai thumper! [02:48] hi beuno [02:49] GungaDin: what are you trying to achieve? [02:51] to patch the changes of a merge. [02:51] I don't want the history tracked. just need to patch. [02:52] GungaDin: you can do that with bzr [02:52] if you merge the branch [02:52] then I think you do bzr revert . [02:52] don't forget the dot [02:52] and I think that merges the content without the history [02:53] but I'd like lifeless or spiv to check that [02:53] bzr revert --forget-merges [02:53] thumper: 'bzr revert .' is the opposite :) [02:53] good thing I checked then :) [02:54] spiv: so with --forget-merges it keeps the file changes? [02:54] GungaDin: So do 'bzr merge' followed by 'bzr revert --forget-merges' [02:54] thumper: yes [02:54] cool [02:54] thanks [02:56] cool. thx [07:48] hi all ! [07:49] Good morning. :) [07:49] morning vila. [07:50] :) [07:55] mgz: do you have a way to reproduce bug #681047 ? [07:55] Launchpad bug 681047 in Bazaar "Random failures on SFTPTransport tests on windows (affected: 1, heat: 6)" [Low,Confirmed] https://launchpad.net/bugs/681047 [07:55] nope, only seen it on babune, as I don't have paramiko installed locally [07:56] mgz: hmm. Do you agree that get_bytes()/get() may be a cause ? [07:57] looked like a good thing to fix, but I'd be suprised if it were the cause [07:57] mgz: taking into account that paramiko do some internals sleep() [07:57] I'm pretty sure that refcounting means the file is closed at the end of that statement [07:58] http://babune.ladeuil.net:24842/job/selftest-windows/242/ <- last run has one of the sftp failures [07:58] ...also has an lsprof thing I don't think I seen before [07:58] 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] 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] which is so vague I don't dare mentioning it usually... [08:03] was guessing something like that [08:05] 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] 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] mgz: by the way, it's nice to have clearer failures in the other cases ;) [10:26] 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] vila: +junk until you decide? [10:40] right [10:40] done: lp:~vila/+junk/bzr-landing-dependencies [10:41] thanks to bzr for reminding at first push, I don't have to note it anywhere... [10:43] vila: you should be able to push it to lp:~bzr/ubuntu/hardy/bzr-landing-dependencies/bzr-ppa [10:44] maxb: brilliant [10:44] done [10:45] maxb: where is this defined ? [10:46] I mean, what are the rules there (especially the 'bzr-ppa' part) ? [10:47] the bzr-ppa part is nothing more than convention established by me [10:49] lol :) Best doc ever ! Ask and you should receive an answer :D [10:49] 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] ok, then, what is allowed under lp:~bzr/ubuntu/hardy/ (this is // right ?) ? [10:50] the rest of the 5-component name is launchpad's schema for identifying source package branches [10:51] so, person/distro/series/package [10:51] even if bzr-landing-dependencies is not (yet?) an "blessed" package ? [10:52] handily using the accidental? feature that even PPA package names work there [10:53] ooooh, so it's not that arbitrary then, it should catch tyops :D [14:03] 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] 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] (Unless something has changed significantly recently...) [14:09] Peng: Thanks. I trust that if it has had that behavior, it still does. :) [14:11] DaffyDuck_`: Check if something has a .bzr/repository to be sure. [14:13] Yeah; my plan was to run "bzr info" to see if it mentions being a part of a repository before nuking anything. [14:29] Yeah, that works too. :P === zyga is now known as zyga-food [15:28] 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] bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ubuntu-virt/vmbuilder/0.12/". [15:29] where does it get this from? I'm pretty sure that lp:~mvo/vmbuilder/add-natty is a branch of lp:vmbuilder [15:29] mvo: Hi [15:29] hey jelmer [15:29] mvo: I suspect lp:~mvo/vmbuilder/add-natty was originally stacked on that other branch but the other branch has been renamed [15:29] or perhaps removed [15:29] should I just apply the diff or is there a better workaround? [15:31] mvo: do you know what happened to the original 0.12 branch? [15:31] I have no idea :( [15:31] 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] 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] can I just mug around in that file to point to a different one? [15:32] mvo: yep [15:32] * mvo puts his cowboy hat on and tries it [15:33] I thought launchpad prevented removing branches that had other branches stacked on them, but apparently there isn't complete coverage. [15:35] 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] worth a bugreport? [15:35] mvo: Yeah, I think so [15:42] bug #681431 [15:42] Launchpad bug 681431 in Bazaar "confusing error when original stacked branch becomes invalid later (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/681431 [15:43] probably needs adjustment, maybe its code-hosting instead of bzr? or both? [15:43] thanks for your help, I was able to workaround it now [15:46] 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] If I understand correctly there's no hook for that at the moment. [15:47] (And unlike in SVN a branch doesn't imply a commit. I like that, but it makes this somewhat unfortunate.) [15:47] Perhaps a push hook? Does the hook know who committed? [15:48] I'm looking at http://wiki.bazaar.canonical.com/BzrHooks, it mentions bzr 1.0 hooks. Is that hopelessly outdated? [15:57] hm, hm, there is https://launchpad.net/vmbuilder/0.12 and claims the 0.12 series points to lp:vmbuilder [16:02] mvo: Note the difference between ~ubuntu-virt/vmbuilder/0.12 and ~vmbuilder-dev/vmbuilder/0.12 [16:03] ohhhh [16:03] Do you need to rescue an existing branch, or have you completely worked around it by repushing a local copy? [16:04] 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] currently [16:05] mvo: Do you have write access to the problem branch? [16:06] lvh: Yeah, I don't think the wiki has been updated - try "bzr help hooks" ? [16:06] not the packaging one :/ to trunk though [16:06] jelmer: Ooooooh. Nice. [16:06] the one I wanted to work on next is lp~soren/vmbuilder/packaging [16:06] jelmer: Thanks [16:06] but that is not owned by me [16:07] 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] mvo: What do you want to do to it? [16:08] 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] Launchpad bug 681431 in Bazaar "confusing error when original stacked branch becomes invalid later (affected: 1, heat: 6)" [Undecided,New] [16:08] soren: it appears its unhappy because its stacked on location changed [16:08] mvo: I'm not even sure I have a local checkout of it. [16:09] mvo: Let me know if I can help. [16:09] soren: Could you download a script I wrote for this purpose? http://j.maxb.eu/~maxb/bzr-set-stacked-url [16:09] oh, nice [16:10] jelmer: None of these hooks appear to know which user did it though [16:10] 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] Then you can run bzr-set-stacked-url lp:~soren/vmbuilder/packaging lp:~vmbuilder-dev/vmbuilder/0.12 [16:10] I'm cooking dinner right now, actually. [16:11] lvh: you can check who committed the revision that was pushed? [16:11] mvo: Can you ping me about it this evening or tomorrow? I'd be happy to help get this sorted out. [16:11] 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] jelmer: Right [16:11] soren, mvo: I'll sort it via scping the branch and push it to lp:~maxb/vmbuilder/packaging [16:11] 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] maxb: cool! many thanks .) [16:11] mvo: Lovely. [16:12] jelmer: post pull and push are client-only, so either I need cooperative clients or something else [16:12] lvh: you can't really rely on anything but the client as bzr supports "dumb" push [16:13] jelmer: I'm working under the assumption everyone does everything over bzr+ssh [16:13] mvo: pushed [16:13] post-branch-init looks promising [16:14] * mvo hugs maxb [16:15] 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] lvh: yeah [16:18] Hm, unfortunate, but I guess I'll live :-) Thanks jelmer :-) === zyga-food is now known as zyga === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: spiv | Release Manager: vila, 2.2.2 has gone gold, packagers of the bzr world, unite ! | Hooray for jelmer [17:04] Hrm. PQM seems to only be accessible under pqm.bazaar-vcs.org, there appears to be no pqm.bazaar.canonical.com [17:05] 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? === beuno is now known as beuno-lunch [17:07] maxb: why ? [17:07] Consistency. AFAIK every other bazaar resource has moved off bazaar-vcs.org [17:08] 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] ..not mentioning the docs... [17:10] maxb: and since there are plans to migrate from pqm to tarmac, I'd rather keep the energy focused on that instead [17:10] ah, ok [17:12] 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] vila: We pop it in the PPA, say, "look, it passes, please rubberstamp that this SRU has met our MRE conditions, thanks" [17:13] maxb: you're just great :D [17:13] Then we validate the package in maverick-proposed did actually build correctly, and say "it works, please promote to maverick-updates" [17:15] right, so I need to setup the right branches on my side and document the above [17:16] 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] i.e. let me try [17:17] lp:~bzr/ubuntu/maverick/bzr/bzr-ppa ? [17:17] or bzr-proposed ? [17:17] nah, bzr-ppa when available right ? [17:27] yes.... but no :-) [17:27] We probably want to prepare the SRU on top of the existing ubuntu packaging branch [17:27] And then just happen to commit equivalent changes onto the PPA branch [17:28] Also, we need to assess the list of bugs fixed by this SRU to prepare an appropriate debian/changelog entry [17:29] 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] I'd can do that tonight if you like [17:40] vila: ^ [17:50] maxb: whatever works for you, I'd be happy to only look as well as being your hands there [17:51] maxb: I'm off now, but I will read the log [17:51] ok === beuno-lunch is now known as beuno [19:48] did I misunderstand, or is bzr merge --interactive broken when it does not record the commit as merge? [19:48] it's plain commit in my history [19:52] ccxCZ: I could believe that it might be deliberate [19:53] 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] well certainly it's not documented in help and now my history messed up :/ [19:53] * maxb reads the source code [19:55] It rather does look like this is the case [19:56] ok I'll remerge that [19:56] but it's kind of nasty, since one might want to cherrypick [20:02] 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] does bzr use launchpad's edge server to decode lp:foo locations? [20:15] 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] Ng: I believe it has done in some versions of bzr. Not sure if it still does, though [20:20] yeah, it's known and known as a bug [20:21] 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] Ng: https://bugs.launchpad.net/bzr/+bug/583667 [20:22] Launchpad bug 583667 in Bazaar "bzr talks to edge API servers to propose merges (but not for lp: url lookups) (affected: 1, heat: 1)" [High,Confirmed] [20:23] ta all [20:34] Ng: what version do you have? [20:34] lifeless: 2.0.4 [20:35] I suspect that still uses edge for lp: [20:47] Ng: This changed in 2.2. Might be worth upgrading, for the steady stream of bugfixes since then [20:47] the bzr --whoami thing is blocking us [20:48] or, at least, that's why we're still on 2.0.4 [20:48] What is the --whoami thing? [20:48] maxb: https://bugs.launchpad.net/bzr/+bug/616878 [20:48] Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (affected: 3, heat: 43)" [Medium,Confirmed] [20:49] elmo: Is your /etc-in-bzr via etckeeper? [20:50] maxb: our setup pre-dates etckeeper, but it's the same idea [21:26] 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] maxb: Yeah, I think that's a good point. Let's not make any unnecessary last minute changes. [21:43] 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] Rather madly, I think bug 659590 is actually the most important fix in 2.2.2 for Ubuntu [22:26] Launchpad bug 659590 in bzr (Ubuntu) "dput sftp upload hangs after all files successfully uploaded (affected: 1, heat: 6)" [Undecided,New] https://launchpad.net/bugs/659590 [22:30] Hrm. [22:30] 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] AAAAAAAAAARRRRRGHH [22:58] Our MicroReleaseException is broken [22:59] We cannot run the testsuite during package build, because bzr is in main, but python-testtools is in universe. [23:22] maxb: :-(( [23:22] maxb: We should really try to get python-testtools into main. [23:22] maxb: But I guess that's not something we could do for this SRU.. [23:23] 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] ( [23:25] :( [23:42] Speaking of which, uploadded 2.2.2 to bzr/proposed now