[00:19] o/ jelmer [09:01] morning all! [09:08] mgz: hey ! [09:08] mgz: can you have a look at https://code.launchpad.net/~vila/bzr/948339-config-caching/+merge/97256 and give me a quick go/no-go for inclusion in 2.6b1 ? [09:11] wow, I don't know what have changed but ./tools/check-newsbugs.py is faster than ever by a significant margin... [09:17] I'll take the credit. [09:28] bad, 3s for 8 bugs in trunk vs 58s for ~141 bugs in 2.5: apples vs oranges [09:29] s/bad/bah/ [09:30] Hm. That's 133 bugs less, a month after the branch. Since it's about 5 months 'till the next branch, that means that 2.6 should have -657 bugs! [09:32] \o/ [09:49] mgz: if you haven't started, forget about it, my RM persona said: too late ;) [09:49] I'vee been looking at it [09:50] ha, thks [09:50] it's really three different things though, and I don't yet understand one of them, and am not convinced by one [09:50] 3 ? [09:51] checking the lock count is straightforward, but lacks a test? [09:51] the list->dict swap for sections I don't see what the bug was previously [09:52] aaron did add a relevant tests IIRC [09:52] and just changing aaron's tests to assert the things that it was calling out as suspect doesn't really seem useful [09:52] they document the expected compatibility (or not) behavior [09:52] the comments are nice, but if you're leaving those issues in place, it's not really the best place for it [09:53] well, the core issue is how far we try to stay compatible and my take is that it contradicts the aim of reducing the IOs [09:53] ^the problem is aaron's test mentioned in that bug, you changed to just assert that the thing that he reckoned was wrong... happened [09:54] so, overall the mp is probably reasonable, but I'm confused. [09:54] the list->dict swap is covered by a failing test encountered while fixing the bug: spurious warnings were emitted because two different callers got two different MutableSection [09:55] mgz: ok, then that's a no-go, no worries [09:56] right, that tests for the same section object is makes that clear [09:56] I shouldn't have tried to get it approved anyway, when the RM says: I'm freezing, it's too late, rushing at this point is just making RM's life harder, I should know ;) [09:56] there's a bug you flipped from 2.6b1 -> None that was just a merge up, was that an accident or is it really not merged? [09:58] it is merged (bzr lp:bzr/2.5 says: nothing to do), I did both cheks at different times may be I should have left the milestone [09:58] bug 939605 [09:58] Launchpad bug 939605 in Bazaar 2.5 "qconflicts says that my merge tool is not available. what should I do?" [Medium,Fix released] https://launchpad.net/bugs/939605 [09:58] will be in 2.6b1 right? [09:58] yup [10:01] I think we should set the milestone only when marking the bug fix released and never before [10:07] jelmer, mgz: by the way, to be clear, I'm freezing 2.6b1, no landings please ;) [10:07] Had I started with that I wouldn't have dared asking for a review ;) [10:09] it's sometimes useful for targetting things that need to be done for a release [10:09] vila: hah, ok [10:09] did bounce? [10:10] I don't see it in the PQM queue [10:10] it's still in my local mail queue [10:10] otherwise, vila that's already sent [10:10] ah, so you can just hold it till vila unfreezes. [10:11] good post on plugin testing jelmer [10:11] jelmer: +1 [10:16] will reply later [10:27] thanks [10:29] jelmer: by the way, any news about bzr-notify dangling progress dialog ? [10:36] vila: haven't worked on that yet [10:37] sumbitting 2.6b1 to pqm [11:04] vila: let me know when I can flush my mail queue :) [11:05] jelmer: I will, waiting for pqm and that's already conflict with my immediate schedule which includes a meeting off the internet in 10 minutes at an 8-minute cycle ride ;) [11:06] ...98% done, but I'm not sure you can do everything remaining in 2 minutes :) [11:10] 2.6b2 open submitted, will finish 2.6b1 later [11:10] * vila runs [12:25] uuurgh, http code 502: Bad Gateway when submitting :-/ [12:58] jelmer, mgz: 2.6b2 opening landed, trunk is free for landing [13:06] \o/ [13:37] hmm [13:37] ValueError: 0 not in range -2147483648 to 2147483647 [13:37] ehehe [13:38] use a bigger 0 [13:41] mgz: re-reading the log: [13:41] it's sometimes useful for targetting things that need to be done for a release [13:42] well, strictly speaking what *needs* to be done for a release ought to be marked critical [13:42] otherwise, vila that's already sent [13:42] ECANTPARSE [13:43] At the time I thought you meant you sent your review but there is nothing there so I was probably wrong ;) === elmo_ is now known as elmo [15:27] is it possible to hook into bzr config from a hook/plugin? [15:32] well, yeah, there are hooks there, what's your need ? [15:32] bzr help hooks [15:34] lamalex: ^ [15:35] jsut for some general configuration. i was wondering if there was already bzr api for using the bzr configuration, rather than rolling my own [15:36] bzrlib.config is the code, doc/developers/configuration.txt and dov/developers/new-config-rationale.txt may be worth a read too [15:37] thanks [15:38] lamalex: if you have a use case that is not covered I'd love to hear about it ;) [15:38] i will let you know after some light reading :) [15:38] k === deryck is now known as deryck[lunch] [16:19] hey [16:19] I'm making a script to deplo udd to an ec2 instance [16:19] it needs openid credentials for the launchpad stuff [16:19] any thoughts on which user I should use in that script? [16:21] ~james_w clearly :) [16:22] heh heh [16:22] there are three approaches I can think of [16:22] can you just make a new one? there are various robotty things, but there's some benefit to keeping them single purpose [16:22] one is to use a fixed use [16:22] user, rather [16:22] the other is to re-use the credentials of the person firing up the instance [16:23] and the third is to make a new user every time [16:23] I think I favour option 1. [16:23] mgz: I can do that. I wonder what LP would think about it. [16:23] I guess I should ask them. [16:23] jml: what's the purpose of the ec2 instance ? Replacing the jubany one ? [16:24] vila: integration testing. [16:24] no write access to lp then right ? [16:24] vila: uhh, I think I would want it to be as close to production as possible [16:25] vila: but I mostly care about emulating the instance on hadar [16:25] vila: and maybe that only has r/o acccess [16:25] jml: we have ~bzr-build-bot for instance just for running things on ec2 [16:25] jml: uhh ? writing to staging then ? You don't want to interfer with the real one right ? [16:26] vila: I don't understand. [16:26] if you can get away with not talking to production launchpad creating a new user each time would be more practical [16:26] jml: you don't want to create the same branches than the importer on jubany right ? [16:27] vila: I'm not creating branches at all. I'm not using lp:udd for anything to do with branches :) [16:28] then I don't understand what you're using it for :) [16:31] vila: lp:udd contains a highly robust, field-tested package monitoring system. We're using that. [16:32] ok, no need for write-access then (AFAIR) [16:32] yeah, I don't think so. [16:32] but lifeless insists that the read access be authenticated. [16:33] then I'd go for 2 or 3 (a dedicated user or the one starting the instance), if anything goes wrong you'll get some trail (sp?) [16:34] 'trail' is correct. [16:34] yeah, so he can kill your bot if needed ;) [16:34] jml, does anonymous with a distinctive token name suffice for him? [16:34] james_w: no, it does not, IIRC. Let me find the thread... [16:35] hmm. I think I might have said user-agent rather than token name... [16:35] I think they are equivalent in lplib [16:35] I think it uses the token name in the user agent [16:35] james_w: https://bugs.launchpad.net/udd/+bug/906846 [16:36] Ubuntu bug 906846 in Ubuntu Distributed Development "Uses authenticated access to Launchpad when anonymous will do" [Undecided,New] [16:38] thanks [16:42] I'm going to be lazy and go with 1 for now. :\ === lifeless_ is now known as lifeless === deryck[lunch] is now known as deryck [18:05] Kbulgrien is idle? [18:14] Given a shared bazaar repository at: /repo and a branch at /repo/prj/bra that contains a folder structure like top/mid/bot, is it possible to make a new branch /repo/prj/mid that has a root at mid of top/mid/bot? IE. A checkout of /repo/prj/mid results in a copy of mid/bot and nothing else from top. [18:16] kevin|: depends exactly what your goal is [18:19] doing `bzr branch prj/bra prj/tmp && bzr split prj/tmp/top/mid && mv prj/tmp/top/mid prj && rm -rf prj/tmp` [18:19] is literally what you're asking for, but perhaps not what you really want. [18:21] partial checkouts haven't been implemented, so you can't work on a subset of the branch then merge it back [18:26] Ok... bummer on no partial checkout but will read up on split. [18:27] Thanks for the tip. [18:35] Isn't bzr view partial checkout? [18:36] no, but it might work for what you want [18:37] it doesn't create a tree with only some elements, rather it restricts operations on an existing tree to a subset === yofel_ is now known as yofel [18:53] I'm doing the 'fake' cherrypicking a revision from trunk onto maintanance branch, why does it not offer to copy the commit message / author / fixes urls / commiters upon bzr commit? [18:54] or what is the proper way to do cherrypick and copy the commit message? [19:04] xnox_: nope, a nicer interface for doing cherrypicks would be good [22:36] hi all [22:38] hihi