| maxb | vila: Does bzr-landing-dependencies have a bzr branch? | 01:17 |
|---|---|---|
| maxb | So are we on for 2.2 today? | 02:17 |
| fullermd | Man, you're behind. I've had 2.2 for months ;) | 02:20 |
| GungaDin | Hi | 02:32 |
| thumper | hi | 02:34 |
| thumper | didn't someone start a gitorious fork using bzr? | 02:34 |
| thumper | anyone know the status of it? | 02:34 |
| GungaDin | Is it possible to generate a diff/patch by simulating a merge ? | 02:41 |
| spiv | GungaDin: 'bzr merge --preview' | 02:44 |
| GungaDin | can that be used with patch? | 02:46 |
| thumper | GungaDin: I believe so | 02:47 |
| beuno | or bzr send? | 02:47 |
| beuno | hai thumper! | 02:47 |
| thumper | hi beuno | 02:48 |
| thumper | GungaDin: what are you trying to achieve? | 02:49 |
| GungaDin | to patch the changes of a merge. | 02:51 |
| GungaDin | I don't want the history tracked. just need to patch. | 02:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| GungaDin | cool. thx | 02:56 |
| vila | hi all ! | 07:48 |
| Peng | Good morning. :) | 07:49 |
| mgz | morning vila. | 07:49 |
| vila | :) | 07:50 |
| vila | mgz: do you have a way to reproduce bug #681047 ? | 07:55 |
| ubot5 | 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 |
| mgz | nope, only seen it on babune, as I don't have paramiko installed locally | 07:55 |
| vila | mgz: hmm. Do you agree that get_bytes()/get() may be a cause ? | 07:56 |
| 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:57 |
| 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? | 07:58 |
| 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:01 |
| mgz | was guessing something like that | 08:03 |
| 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:05 |
| 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:06 |
| vila | mgz: by the way, it's nice to have clearer failures in the other cases ;) | 08:16 |
| 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:26 |
| spiv | vila: +junk until you decide? | 10:37 |
| vila | right | 10:40 |
| vila | done: lp:~vila/+junk/bzr-landing-dependencies | 10:40 |
| vila | thanks to bzr for reminding at first push, I don't have to note it anywhere... | 10:41 |
| maxb | vila: you should be able to push it to lp:~bzr/ubuntu/hardy/bzr-landing-dependencies/bzr-ppa | 10:43 |
| vila | maxb: brilliant | 10:44 |
| vila | done | 10:44 |
| vila | maxb: where is this defined ? | 10:45 |
| vila | I mean, what are the rules there (especially the 'bzr-ppa' part) ? | 10:46 |
| maxb | the bzr-ppa part is nothing more than convention established by me | 10:47 |
| 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:49 |
| 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:50 |
| maxb | so, person/distro/series/package | 10:51 |
| vila | even if bzr-landing-dependencies is not (yet?) an "blessed" package ? | 10:51 |
| maxb | handily using the accidental? feature that even PPA package names work there | 10:52 |
| vila | ooooh, so it's not that arbitrary then, it should catch tyops :D | 10:53 |
| 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:03 |
| 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:05 |
| Peng | (Unless something has changed significantly recently...) | 14:06 |
| DaffyDuck_` | Peng: Thanks. I trust that if it has had that behavior, it still does. :) | 14:09 |
| Peng | DaffyDuck_`: Check if something has a .bzr/repository to be sure. | 14:11 |
| DaffyDuck_` | Yeah; my plan was to run "bzr info" to see if it mentions being a part of a repository before nuking anything. | 14:13 |
| Peng | Yeah, that works too. :P | 14:29 |
| === zyga is now known as zyga-food | ||
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 | |
| jelmer | I thought launchpad prevented removing branches that had other branches stacked on them, but apparently there isn't complete coverage. | 15:33 |
| 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:35 |
| mvo | bug #681431 | 15:42 |
| ubot5 | 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:42 |
| 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:43 |
| 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:46 |
| 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:47 |
| lvh | I'm looking at http://wiki.bazaar.canonical.com/BzrHooks, it mentions bzr 1.0 hooks. Is that hopelessly outdated? | 15:48 |
| mvo | hm, hm, there is https://launchpad.net/vmbuilder/0.12 and claims the 0.12 series points to lp:vmbuilder | 15:57 |
| maxb | mvo: Note the difference between ~ubuntu-virt/vmbuilder/0.12 and ~vmbuilder-dev/vmbuilder/0.12 | 16:02 |
| 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:03 |
| 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:04 |
| maxb | mvo: Do you have write access to the problem branch? | 16:05 |
| 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:06 |
| 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:07 |
| 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 |
| ubot5 | Launchpad bug 681431 in Bazaar "confusing error when original stacked branch becomes invalid later (affected: 1, heat: 6)" [Undecided,New] | 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| * mvo hugs maxb | 16:14 | |
| 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:15 |
| jelmer | lvh: yeah | 16:17 |
| lvh | Hm, unfortunate, but I guess I'll live :-) Thanks jelmer :-) | 16:18 |
| === 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 | ||
| maxb | Hrm. PQM seems to only be accessible under pqm.bazaar-vcs.org, there appears to be no pqm.bazaar.canonical.com | 17:04 |
| 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:05 |
| === beuno is now known as beuno-lunch | ||
| vila | maxb: why ? | 17:07 |
| maxb | Consistency. AFAIK every other bazaar resource has moved off bazaar-vcs.org | 17:07 |
| 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:08 |
| vila | ..not mentioning the docs... | 17:09 |
| 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:10 |
| 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:12 |
| 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:13 |
| vila | right, so I need to setup the right branches on my side and document the above | 17:15 |
| 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:16 |
| vila | lp:~bzr/ubuntu/maverick/bzr/bzr-ppa ? | 17:17 |
| vila | or bzr-proposed ? | 17:17 |
| vila | nah, bzr-ppa when available right ? | 17:17 |
| 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:27 |
| maxb | Also, we need to assess the list of bugs fixed by this SRU to prepare an appropriate debian/changelog entry | 17:28 |
| 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:29 |
| maxb | vila: ^ | 17:40 |
| vila | maxb: whatever works for you, I'd be happy to only look as well as being your hands there | 17:50 |
| vila | maxb: I'm off now, but I will read the log | 17:51 |
| maxb | ok | 17:51 |
| === beuno-lunch is now known as beuno | ||
| 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:48 |
| maxb | ccxCZ: I could believe that it might be deliberate | 19:52 |
| 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:53 | |
| maxb | It rather does look like this is the case | 19:55 |
| ccxCZ | ok I'll remerge that | 19:56 |
| ccxCZ | but it's kind of nasty, since one might want to cherrypick | 19:56 |
| 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:02 |
| 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:15 |
| 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:20 |
| 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:21 | |
| lifeless | Ng: https://bugs.launchpad.net/bzr/+bug/583667 | 20:22 |
| ubot5 | 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:22 |
| Ng | ta all | 20:23 |
| lifeless | Ng: what version do you have? | 20:34 |
| Ng | lifeless: 2.0.4 | 20:34 |
| lifeless | I suspect that still uses edge for lp: | 20:35 |
| 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:47 |
| 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:48 |
| ubot5 | Launchpad bug 616878 in Bazaar "bzr commit error because of no identity (affected: 3, heat: 43)" [Medium,Confirmed] | 20:48 |
| maxb | elmo: Is your /etc-in-bzr via etckeeper? | 20:49 |
| elmo | maxb: our setup pre-dates etckeeper, but it's the same idea | 20:50 |
| 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:26 |
| jelmer | maxb: Yeah, I think that's a good point. Let's not make any unnecessary last minute changes. | 21:30 |
| 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 | 21:43 |
| maxb | Rather madly, I think bug 659590 is actually the most important fix in 2.2.2 for Ubuntu | 22:26 |
| ubot5 | 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:26 |
| 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:30 |
| maxb | AAAAAAAAAARRRRRGHH | 22:58 |
| maxb | Our MicroReleaseException is broken | 22:58 |
| maxb | We cannot run the testsuite during package build, because bzr is in main, but python-testtools is in universe. | 22:59 |
| 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:22 |
| 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:23 |
| lifeless | ( | 23:25 |
| lifeless | :( | 23:25 |
| maxb | Speaking of which, uploadded 2.2.2 to bzr/proposed now | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!