=== michaelh1 is now known as michaelh1|away === michaelh1|away is now known as michaelh1 [09:17] morning! [09:29] mgz: my man ! :) [09:30] * fullermd used to be your man :( [09:30] I can't find the bug about the recent spurious failures on babune, do you ? [09:31] fullermd: hehe, I can multi-man for some contexts ;) [09:31] * fullermd c&p's into his quotes file. [09:31] hehe, see if I care ;) [09:33] fullermd: by the way, did you try to run the full test suite lately ? [09:33] fullermd: I remember you had issues and mgz landed a patch on trunk that we hope should address them [09:33] Nah. I'm just an optimist and assume it'll work. [09:35] mgz: also, I just noticed you use 'test' and 'test-failure' as bug tags where I was assuming 'selftest' myself, we should probably discuss and agree on which one(s) we use [09:36] mgz: oh, and 'babune' is also relevant [09:36] Seems the last time I tried a full run (which was however many $AGES ago) I always had the deadlocks run up. [09:36] you edited oneyou want bug 874153 vila? [09:36] Launchpad bug 874153 in Bazaar "Spurious test failure" [High,Confirmed] https://launchpad.net/bugs/874153 [09:37] ... [09:37] one you just edited, and I think that's the other current one [09:37] YES ! [09:38] I try and remember to use selftest for... issues with selftest itself, and generally don't tag test failures in any particular way [09:40] ha, right, poolie seems to be using test-failure [09:41] yeah, keeping 'selftest' for selftest itself seems like a better fit [09:42] I think I'll switch to 'test-failure' for regressions triggered on babune [09:45] bbiab === michaelh1 is now known as michaelh1|away === michaelh1|away is now known as michaelh1 [10:47] vila: how far back are we backporting fixes currently? [10:48] this bug report is against 2.1.4, the change is against 2.3 and we're on 2.5 [10:49] I'll propose against 2.3 for now I guess === zyga-afk is now known as zyga === michaelh1 is now known as michaelh1|away [11:58] mgz: for bug #874153 ? spurious enough to target trunk only I'd say [11:58] Launchpad bug 874153 in Bazaar "Spurious test failure" [High,Confirmed] https://launchpad.net/bugs/874153 [11:59] mgz: oh no, 2.1.4, dunno which bug you're referring then [12:01] hi [12:02] vila: https://code.launchpad.net/~gz/bzr/2.3_unprintable_retrywithnewpacks/+merge/81827 [12:02] hi hrw [12:03] hey hrw, getting on okay with the buildds now? [12:04] mgz: works great [12:04] briandealwis: hi [12:04] mgz: thanks a lot for this change [12:04] hi vila [12:05] jelmer and poolie were slaving away on getting it deployed all week we were at UDS :) [12:05] (and jelmer had been trying for... I don't want to know how long before that) [12:05] but the question for today is: how to export set of revisions as separate patches. I need to merge some changes from one branch to other but they have no common ancestor so prefer to have patches (like I would do with git and git format-patch) [12:06] if you have both branches, you can cherry-pick the revisions, rather than going via patchfiles [12:07] I cannot export some of changes as they are one huge commit [12:08] anyway, bzr diff with the revision range? depends how you want to edit the patch. [12:09] if your normal git thing is to get interactively select hunks, I'm not sure what would suit you best. [12:09] moment - phone call [12:10] vila, I haven't had time to do any further work on hooks-related part. The exception-shielding code comes from some nearly inexplicable interactions I've witnessed from exceptions in hooks. I've nearly reported 3 bugs on bzr-svn or bzr-git that were due to hooks instead. But I see your points about hooks being able to influence the execution too. Seems we want a HookPoint.run for both with and without exceptions [12:11] (sorry for the wall of text) [12:11] briandealwis: great, I was worrying you got confused by the reviews across both proposals [12:12] not at all [12:12] briandealwis: do you recall what those hooks were? bzr-git and bzr-svn only hook into the "info" and "version-info" commands. [12:13] briandealwis: as said, if you've got enough use cases to triangulate, run_without_exceptions makes sense for purely innocuous hooks [12:13] ah, bzr-git hooks into Branch.hooks['post_commit'] too [12:13] but as soon as we start playing tricks with return values or stopping hook execution when some condition is reached, run() itself becomes less attracting [12:13] jelmer: it was due to one of my own plugins :) I have a 'verbose_hooks' plugin for debugging that dumps info on the hook args for various hooks. There was an error in one of the branch hooks with bzr-git as it doesn't support generating a revno [12:14] So I'd do a dpush, which would throw an exception [12:14] I was uncertain as to the state of the branch or the push [12:14] ah, ok [12:15] So from a user's perspective, providing the exception was far more confusing an experience [12:15] Or rather, showing the exception without context, was confusing [12:15] briandealwis: that being said, I think my review was more about splitting the proposal to separate the parts we all agree upon from the parts for which more discussion may be needed [12:16] I moved out the exception-shielding-run into HookPoint at poolie's request :) [12:16] it generally makes it a more satisfying experience for both the submitter (stuff lands) and the reviewer (easier to review) [12:17] briandealwis: yup, I realized that *after* my review [12:17] briandealwis: cross reviews are ... confusing :) [12:17] or rather reviews across resubmitted proposals [12:18] briandealwis: you know you can just push on the same branch ? [12:18] I wondered about adding BZR_PDB support, so the exceptions could be seen and debugged, but it looked harder than I thought [12:18] re: pushing: I did, but on a previous proposal, I thought I was told to resubmit [12:18] …but that was a while ago [12:19] (the distinction between re-submitting or just pushing is rather arbitrary) [12:19] and even reviewers may say resubmit for push adding to the confusion ;) [12:19] ah that would make sense [12:20] it's a judgment call but generally re-submitting is when you want to really re-start the review from scratch because the first proposal is becoming too... complex/diverging from initial intent/whatever [12:21] gotcha [12:21] oops, I mean: got it [12:21] * vila blinks, the subtle difference between 'gotcha' and 'got it' here escapes me... [12:22] gotcha seems to have more of a connotation of a surprise. I think. In my head at least. [12:22] didn't 'gotcha' mean: 'I got what you said' ? [12:23] oh [12:23] thks [12:32] jelmer, mgz: freezing 2.5b3, please don't land, I'll do as fast as possible and tell you when I'm done [12:42] Riddell: ping [12:47] Hi! I'm writing a launchpad recipe and when I'm testing it I have to enter my key passphrase 10 times, although read access to these branches are public...? [12:48] diwic: you may be interested in an ssh-agent ? [12:49] diwic: as soon as you tell lp about your ssh key, ssh will be preferred to http for performance reasons [12:50] vila, hmm, how do I set up an ssh-agent? I tried just running "ssh-agent bzr dailydeb recipe" but it didn't help [12:51] mgz: for f in `seq 1 12`;do bzr diff -c$f >$f.diff;done [12:51] diwic: depends on your os/distro, which are you using ? [12:51] Ubuntu 11.10 [12:51] mgz: that what I needed ;) [12:53] * vila blinks, wth are the key settings gone, can't find them anymore in system settings [12:54] diwic: On ubuntu the ssh-agent should already be running... 'ssh-add -l' should tell you which keys are known [12:55] diwic: 'ssh-add ' will add a new one [12:55] vila, aha, thanks, that was helpful! [12:55] My recipe still fails though :-( [12:56] bzr: ERROR: No such tag: upstream-3.0.0 [13:09] * diwic files bug 888539 [13:09] Launchpad bug 888539 in bzr-builder (Ubuntu) "Recipe fails with "bzr: ERROR: No such tag: upstream-3.0.0"" [Undecided,New] https://launchpad.net/bugs/888539 [13:10] hi diwic [13:11] jelmer, hi there! [13:11] diwic: is this on a local build, or using Launchpad? [13:11] (It shouldn't happen using Launchpad) [13:11] jelmer, this is local, testing it before trying it on Launchpad [13:12] jelmer, with 0.7.1-0ubuntu1 of bzr-builder package [13:12] diwic: --force-native-mode or sth like that is needed then [13:12] diwic: --allow-fallback-to-native [13:13] diwic: newer versions of bzr-builder should give you a clearer error message [13:13] diwic: it will ignore tags and force native package [13:14] * diwic tries "bzr dailydeb --allow-fallback-to-native recipe" [13:14] hrw, thanks for keeping me awake at the airport btw :-) [13:15] I'll release 0.7.2, there are a couple of other fixes that would be nice to get out too [13:15] hrw & jelmer, it worked, thanks! [13:15] diwic: no problemo [13:15] diwic: I had this problem (bzr) before [13:16] diwic: on return path I missed someone to keep me alive - had to rebook flight from FRA to TXL as I missed it (they moved gate and I did not noticed) [13:17] hrw, oh :-( but it got sorted out I hope [13:18] jelmer: hi! :) [13:21] Wellark: hi :) [13:23] diwic: yes [13:23] diwic: and they did not charged me === yofel_ is now known as yofel [13:40] vila: pon [13:41] g [13:42] Riddell: I tried to follow your instructions to update po/bzr.pot [13:42] and I encountered weird stuff [13:42] what did you do? [13:43] I finally used 'BZR_PLUGIN_PATH=-site make po/bzr.pot' instead of 'make -f po/bzr.pot' [13:43] and froze 2.5b3 with that [13:43] I wanted to make sure excluding the plugins was the Right Thing to do [13:44] yes it is [13:44] otherwise the ones included depend on the RM :-/ [13:44] ha good [13:44] I've updated the instructions then and I'll send a mp asap [13:51] Riddell: the associated diff is an interesting way to look at what has been added since the previous release... [13:51] Riddell: good stuff for RMs ;) [13:58] jelmer, mgs: 2.5b3 frozen, 2.5b4 opening on pqm, thanks for your patience ;) [13:58] s/mgs/mgz/ [13:58] vila: thanks! [13:58] stick the strings file diff up somewhere vila? :) [13:59] mgz: 'bzr pull lp:bzr' , it's part of the release commit [13:59] an extractable part though? :) [13:59] * mgz tries [14:00] the release commits are quite short most of the time [14:01] hehe, I just add a wtf moment: I misread 'test_non_ascii.TestNonAscii.' as '^[ascii]' and thought pqm was back in the good old days where we ran the test suite twice ;) [14:01] bah [14:01] a bunch of line number change junk [14:02] * mgz grumbles at gettext and the formats it uses [14:02] hmm, that reminds me that ediff (in emacs) allows regexps to *ignore* some changes... [14:07] hm, command help paragraphs don't seem to be shared, eg bzrlib/builtins.py:1007 and bzrlib/builtins.py:1147 [14:18] Hi there, do you guys happen to know if it's possible to have a mirrored branch inside /~me/+junk/ on lp? Or do I have to create a project and create the mirrored branch in there? [14:18] I've been sent here from lp-dev so please don't send me back there ;) [15:08] We really should switch up metals for some variety. [15:09] Our next beta should go palladium, say. [15:11] palladium is one of the launchpad buildds [15:11] OK, ruthenium then. [15:22] fullermd is bored of gold by now? [15:22] just have too much, don't know what to do with it? [15:25] Nono, I don't have *enough*! And all those betas keep going off with what I have! [15:57] mgz: yup, I noticed the help paragraphs too... did you dig that ? [15:58] nope, but I did notice one was at the end of the help block and one in the middle [15:58] so could be a quirk of how that's split [15:59] or perhaps help blocks aren't deduped at all. [16:00] Maybe a final \n quirk [16:00] really, it's a sign that our help needs shortening I thikn === beuno is now known as beuno-lunch [16:07] vila: 2.5b3 uploaded to sid/precise [16:07] sorry, experimental+precise [16:09] jelmer: Thanks ! [16:10] vila: looks like export_pot doesn't actually do deduping. [16:10] mgz: export-port is ours right ? [16:11] yup, bzrlib.export_pot [16:11] ok, worth a bug then [16:12] 2.5 is the first series for translations, it's expected that we encounter a few [16:12] bugs [16:12] I better read up on the po format first... :) [16:12] hmm, and PEP8 issues there too ;) [16:13] jelmer: I kinda lost track of where you are for multiple tarballs, but [16:14] jelmer: IIUC you commented a line related to branch freshness and this is causing other import failures [16:14] jelmer: is there two different bugs ? [16:14] hgaaa [16:15] jelmer: I meant: commenting that line (which one ?) will *address* other import failures that we encounter *now* [16:15] as I recall, he only commented a line on his box, for testing, which was a path the importer doesn't go down [16:15] the freshness issues should be all the same old freshness issues [16:15] mgz: yup [16:16] http://package-import.ubuntu.com/status/3b90b26b3585bde1d5cb6d903f83dc45.html [16:16] looks new to me [16:16] imbw but it seems that running bzr-2.5 on jubany has caused these new failures [16:16] which is surprising in itself [16:17] but checking the freshness on the importer seems useless anyway so we probably want a way to disable it if only for the importer [16:20] vila: I wouldn't be suprised if fixing the multiple tarballs error exposed a few more packaged with freshness issues [16:21] vila: it works at the moment [16:21] vila: but I'm fixing a bug in the multi tarball support to handle revisin parents correctly [16:22] mgz: the importer is responsible to make the branches fresh enough is what I'm trying to say ;) [16:22] this is pretty fun too: http://package-import.ubuntu.com/status/73d7709fb86e524d019e4c119d698c58.html [16:22] jelmer: ok, so I'm still waiting for your green light [16:24] mgz: that's one of the bugs where I suspect the importer misunderstands the packager [16:24] vila: yep [16:24] yeah. [16:37] vila: do you favour merging up older bzr releases when each change lands? [16:45] mgz: yup, that means the guy doing the landing also handle the conflicts when merging up [16:45] mgz: and they should be easier to resolve by him than by anybody else [16:47] heh, anyone can read release notes and probably realphabetise better than me :P [16:48] oh, release notes, yeah, be careful when crossing... 2.2 -> 2.3 where they were split from NEWS to one file per release [16:49] but release notes is not my concern here ;) === beuno-lunch is now known as beuno === deryck is now known as deryck[lunch] [17:42] wgz: confused by the too many spurious test failures, I ended up filing a bug you already filed, in anger, I marked *yours* as a dupe of mine ;) === deryck[lunch] is now known as deryck [18:23] hey all. how can i track a git repository in bzr ? [18:23] i know i can set up launchpad to do it for me [18:23] hi smoser [18:23] but how can i do it on my own? [18:23] smoser: if you have bzr-git installed, just use bzr branch as you would with a bzr branch [18:24] perfect. [18:25] easiest question ever [18:25] thank yoiu [19:36] I can't seem to get Bazaar to pull from an HTTP server. [19:37] Using Chromium, I can verify the remote server is up and running and the .bzr folder is accessible. [19:37] ...but I keep getting errors: "bzr: ERROR: Not a branch: 'http://192.168.1.1:8083/'" [19:39] What am I doing wrong? [19:40] hi george_e [19:40] Hi. [19:40] george_e: is .bzr/branch-format accessible? [19:41] * george_e slaps forehead [19:41] It's spitting out a 403 :) [19:41] That would explain it alright. [19:41] (That's what I get for using IIS :P) [19:44] jelmer: Thank you thank you thank you - that solved the problem. [19:45] george_e: np :) [23:03] hi all [23:09] hi poolie [23:09] hi jelmer [23:09] poolie, [23:09] hi [23:18] hi poolie, GRiD, Noldorin [23:18] hey [23:19] hey jelmer [23:19] how's it going? [23:21] no hurry, but if someone can take another look at https://code.launchpad.net/~weyrick/bzr/720853-max-recursion-depth/+merge/81297 ... [23:21] oh thanks for th ereminder [23:24] done [23:27] thanks :) [23:29] jelmer, are we any closer to the new bzr-git release/fix, may i ask? :-) [23:33] poolie, btw, i suppose i should also add something to release-notes? [23:33] yes [23:35] k