[01:55] OOPS-2062AZ5 too late at night... [01:57] Fourth time lucky, I wonder if putting "lp:" on the start of the prerequisite branch upset anything... [01:58] mgz: bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout [01:58] 77 results being the relevent thing? :) [01:59] no, there is one for +merge-proposal in there ;) [02:00] bug 629087 looks likely. [02:00] Launchpad bug 629087 in Launchpad itself "Branch:+register-merge timeout submitting merge proposal" [Critical,Triaged] https://launchpad.net/bugs/629087 [02:00] yeah thats the one [02:00] * mgz metoos === ScottK2 is now known as ScottK [04:00] hi mgz, scottk [04:07] hello poolie. [04:07] poolie: It's gone midnight, so I'm about to go to bed, but what's up? [04:07] just saying hi [04:07] thanks for the suggestion [04:07] about out of date branches [04:07] Ah. OK. [04:08] Hello back poolie. [04:26] heya. [04:28] how do i tell what gets called when you pass commands to bzr? like, bzr add, checkout, merge, etc [04:29] AuroraBorealis: do you mean what python functions run? [04:29] yeah [04:29] i see the Command class and that you have to register [04:29] said commands but i dunno where that gets done o.o [04:29] for plugins during the plugins __init__ [04:30] for core commands by being in builtins.py [04:30] or whatever the file is called :) [04:32] ah, thank you =) === Topic unset by poolie on #bzr [05:29] oh gee. === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: JAM [06:18] hi all ! [06:20] hi... [06:20] where does the InventoryEntry object store its 'kind' variable? [06:21] i keep seeing it referenced but i never see it created, its not created in __init__ and ctrl+f shows its not created anywhere else in inventory.py.. [06:25] never mind i'm stupid, its in the subclasses. although said methods are calling that variable in the super class so they would throw errors if you called said method on the superclass o.o [08:30] Hi Everyone, quick question. I'm reading up a lot about why you shouldn't push a feature branch directly upstream. I was just wondering if there was a way to enforce non changing id numbers so the people I work with don't accidentally do this [08:31] ChrisCauser: yes, set append_revisions_only [08:31] Brilliant. Many thanks [08:38] vila, so if you look at jam's recent get_parent_map work [08:38] i think there's a constant in it which he did some empirical work to change [08:38] yup [08:38] i think i suggested it could be configurable and he opted not to [08:38] indeed [08:38] for backport reasons [08:38] mm [08:39] which is tangential but could become a concern if we never use new features by fearing backport issues, but that's not the main point here [08:39] so, i don't think going back and changing it to be configurable, which would potentially close 832061, would be especially useful in itself [08:40] I trust jam's work on setting the "best" value here, but that doesn't mean that for some setups this value will be far from optimal [08:40] sure [08:40] if we can't try new values, we'll never know [08:41] and if the code evolves and the best value is not the best anymore, we'll never know either [08:41] poolie: I also didn't want to introduce yet-another-read of something that doesn't-really-need-to-be-set [08:41] right [08:42] and if this constant turns out to be easily tweaked based on some (for the sake of the example) branch history property, we can't tweak either [08:42] so, basically [08:42] jam: right, that's a performance issue [08:42] i like bugs that correspond to actual problems and where you can tell whether they're fixed or not [08:43] if you find a way to tweak that constant, or to dynamically configure it to make things faster, that's great [08:43] well, not being able to diagnose whether a constant is good or bad *is* the problem I'm referring to [08:43] vila: so if it was something like "disable it completely" I would consider a config item. If it is just tweaking it, it really depends on how much effect it could have. [08:43] Since my experiments said "very little" outside of edge cases [08:44] so, being able to change a thing when we don't have any actual reason to think we want to change it is Low [08:44] there are a lot more important bugs than that [08:44] well, I won't ask you to extend your experiments to lp hosted code... [08:44] vila: so in *this particular* case, I did a fair amount of analysis and testing (a couple days at least) to know that the setting was not going to be very optimizable. I don't know that it applies in every case [08:44] vila: that was tested on lp hosted code [08:45] *all* lp hosted code [08:45] vila: I don't think we really care about the perf on lp:bzrtools as long as it is reasonable, and I tested against lp:gcc-linaro lp:mysql and lp:emacs [08:45] so, vila, if you had a good reason to suspect that by further tweaking we could get a big improvement, i'd say go for it [08:45] I suppose I could do lp:launchpad [08:45] but I did try to do different types of histories, etc. [08:45] but that doesn't seem to be where we are [08:46] Yes, this experiment could be done again in a year, etc. But honestly, unless someone is going to spend the time analyzing the results, it won't help much. [08:46] poolie: it's not about *me* it's about anybody willing to try with its *own* know code [08:46] And if they are doing that, they don't need a config setting [08:46] what do they need then ? Modifying the code ? [08:46] vila: sure, or a plugin that modifies the constant, or ... [08:46] so if someone is going to tune this, it's probably pretty easy for them to make it configurable at that point [08:46] in the end, you need to write a script [08:47] and that can fairly easily get at what you need [08:47] or just a fix for bug #491196... [08:47] Launchpad bug 491196 in Bazaar "want a way to set configuration options from the command line" [Medium,Confirmed] https://launchpad.net/bugs/491196 [08:47] i think adding a command-line option is possibly the thing that would help them most [08:47] right, i would say that is far in advance of going back and making every thing configurable [08:47] i think too, many things that could be tuned don't want to be tuned by just changing an integer [08:47] but possibly changing the algorithm, which is beyond what this can do [08:48] right, changing algorithms is better done via hooks [08:48] but hooks can also be configured [08:48] or experimenting with an actual patch [08:48] vila: or you can write a plugin... [08:48] or monkey patch, or. [08:49] honestly, if someone wants to experiment with the code, I really don't see a huge difference from them playing with the *code* [08:49] jam: or set a command-line option, which one is the easiest for someone wanting to experiment without knowing the code base ? [08:49] vila: someone who wants to tweak this is going to need to know a whole lot more than a command line option [08:49] note *this* [08:49] Some other things would be good with a command line/environment var [08:50] vila, a command line option would be great [08:50] very nice for interactively testing config related stuff, aside from anything else. [08:51] vila: I agree that having a config item that can be set from a command line (env var, argument passed) is the easiest way to play with bulk behavior. [08:51] In this case, I think it is YAGNI. [08:51] You also want to avoid doing the whole fetch [08:51] so you need to hack the code anyway [08:51] vila do you see what i mean about prefering 'know you're done when' bugs? [08:51] otherwise the 1-5min startup time is lost in the 30min transferring 600MB of data. [08:52] vila do you see what i mean about prefering 'know you're done when' bugs, and why this isn't really one at the moment [08:54] poolie: yes, but we disagree on "it's done" :) [08:55] when would it be done? [08:55] we had many cases in the past where one setting (let's just say 'encoding') wasn't properly found (for whatever reasons) and users were blocked because there was no way to override this setting [08:56] yup [08:56] i would certainly agree with that [08:57] in fact i think i have filed a bug about that particular case, or at least someone has [08:57] If we can associate that kind of setting with a *config* setting, we can at least say: 'Look, we'll fix that in the latest stable series, in the mean time, just set it to x in this context) [08:58] I argue that whatever setting (constant or not) should be a config setting to cover these cases and I'd call it done when the know ones are [08:58] yep [08:58] if it names some specific things that aren't configurable but should be i'd be totally fine with the bug [08:59] (bit questionable whether to have one bug or several but the simplest thing would be to start with one) [08:59] perhaps better to fix the bugs that are already filed though [08:59] :) [08:59] some of them, like fsenc, are nontrivial to change [09:00] vila: we've had code bugs in the past that we couldn't fix in the stable release. If we could write some python config values we could say "write this config and it will fix the bug for now". [09:00] oh, that is a plugin... [09:00] I'll agree that 'config' seems a little better than a plugin. [09:00] meaning "lighter for the user" [09:00] and doesn't require python knowledge [09:01] I argue that it it was that easy to write a plugin we'll have far more of them today [09:01] vila: but does require to know the config value to set [09:01] and if we have to give them something to use [09:01] we can give them the plugin [09:02] I'm not saying plugins are bad and should never be written, I'm saying that too few people can write them or even install them [09:02] ok... [09:02] jam: look at bug #320593 and tell me how long the proposed plugin will work [09:02] Launchpad bug 320593 in Sedot "nggak bisa buat file rrd setelah ganti system" [Undecided,Fix released] https://launchpad.net/bugs/320593 [09:02] shudder [09:03] vila: I'm arguing that the set.difference() between set(users_can_set_a_config_we_recommend).difference(set(users_that_can_install_a_plugin_we_recommend_on_a_bug)) is small [09:03] jam: look at bug #302593 and tell me how long the proposed plugin will work [09:03] Launchpad bug 302593 in Bazaar "Reading options for a branch from locations.conf fails with bzr+ssh" [Medium,Confirmed] https://launchpad.net/bugs/302593 [09:04] jam, could you review or maybe finish off https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381 some time? [09:04] vila: longer than writing a config item for it [09:04] poolie: it is in my "in progress" queue [09:04] so yes [09:04] cool thanks [09:05] jam: huh ? Turning a constant into a config item should be a one-liner (if you exclude the help which you need to write anyway) [09:05] vila: "Reading options for a branch from locations.conf fails with bzr+ssh " [09:05] are you sure you were on the right bug? [09:05] vila, so [09:05] let's see if i understand [09:05] you think that generally speaking we should have configs-with-defaults rather than magic numbers [09:06] jam: https://bugs.launchpad.net/bzr/+bug/302593/+attachment/1157814/+files/fixLocationConfigForBzrSsh.py [09:06] Ubuntu bug 302593 in Bazaar "Reading options for a branch from locations.conf fails with bzr+ssh" [Medium,Confirmed] [09:06] poolie: yes [09:06] i agree with that, though i'd have some concern about the scalability of documentation if it includes lots of stuff most people should never change [09:06] some of them should perhaps be debug flags with values [09:06] vila: but you could never fix that with a config change [09:06] poolie: which is bug #746993 [09:06] Launchpad bug 746993 in Bazaar ""bzr help configuration" looks awful" [Medium,Confirmed] https://launchpad.net/bugs/746993 [09:06] iiuc you also think we should go back and look for all things that could potentially be config options and change them [09:06] so yes, the plugin is fragile, it works until you can upgrade to a newer release which has the bug fixed [09:07] and the failure is so large in scope that it is completely outside of "tweaking a config item" [09:07] well, it goes beyond that, into perhaps having an 'internal' or 'hidden' class of options [09:07] i don't think that's worth doing until there's actually a motivation to change them [09:07] poolie, vila: We've also falling into the trap in the past of having configurable settings that people can tweak, but not providing a good default. [09:08] because we stop at "ok, they can configure it" [09:08] that's a risk too [09:08] and defaults really do matter [09:08] know risk [09:08] known risk, but I'm talking about the other end of the spectrum where there is *no* way to change it [09:09] vila: I feel we got a bit off on the wrong foot, though. I agree that *in general* I'd rather have something exposed to the user easily in case something goes wrong. [09:09] This particular case, the reward / benefit was not high enough. [09:09] When we have properly cached configs, that may change. [09:09] cool [09:09] jam: pfew, thanks [09:09] vila: note that I was clear all along that *this case* was how I handled it. [09:10] jam: right, I never said you did wrong given the existing code base 1 [09:11] I'm saying many problems we encountered *could* be far easier to address [09:11] poolie: yes, this may not be the first thing to work on *today* but I'd like us to keep it in mind and not punting every time [09:12] ok, i just read https://bugs.launchpad.net/bzr/+bugs?field.tag=config [09:12] poolie: in that respect, I feel that 'low' is pretty close to 'wontfix' [09:12] i think the ones that are High are plausibly high [09:13] well, those are the ones I filed yesterday (except for the first one), I didn't touch the others but I took them into account when writing the devnotes/configuration.txt [09:14] vila: the flip side of the argument is that you've spent a fair amount of time reworking the config stuff, which still isn't quite enough of a change, vs just fixing the bugs we run into that could have been easier with a better config system. [09:14] (limited human time and all that) [09:14] I really like where you are pushing config [09:14] I'm not sure if it was the optimal use of time [09:15] jam, yeah, that's why i'm looking at that list [09:16] perhaps vila can finish up the High bugs there and any that naturally fall out from doing it and then move on for a bit [09:16] perhaps to udd [09:16] jam: my counter-argument to that is that I didn't spent that much CPU time on it considering the results and that we are now with two designs in flight and that is already a concern [09:17] vila: sure, I certainly think it has been started, it is in flight, we need a clear landing for it [09:17] as poolie said, a clear "it is done" [09:17] but I think you're at a point it can be ratcheted down [09:18] rather than a primary focus. Perhaps not [09:18] well, it's certainly not the only thing I'm working on and I fail to see which of the ~10 mps landed in the last 15 days is not on the cirtical path [09:20] so, in (which may be lossy) [09:21] i see 7 for the last month, and 3 are config related (of which 1 is my fdatasync bug, and fairly serious) and 4 are test suite failures [09:21] poolie: yup, definitely lossy because I didn't file bugs I was fixing (at the some time slicing the features doesn't match filing bugs in my mind but I can change that (which I started yesterday)) [09:26] anyhow, i think john and i are just keen to have config infrastructure and also to get your help on other things [09:42] vila: poke about https://code.launchpad.net/~vila/bzr/missing-stacks/+merge/71918 [09:42] You said "Remote branches ignore bazaar.conf and locations.conf" care to clarify? [09:43] it sounds dangerously wrong [09:43] as locations.conf is provided as a way to *override* settings in branch.conf for remote items. [09:43] remote branches [09:46] Hi. I'm hoping someone can help me decipher this error message: [09:46] bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/%2Bbranch/nova/" and relative path "../../../~soren/nova/trunk/" [09:46] It's in response to "bzr lp-propose-merge -m 'something'" [09:46] http://paste.ubuntu.com/673669/ is my ~/.bazaar/locations.conf [09:47] And I have *no* clue what ../../../~soren/nova/trunk/ is. [09:53] Oh. It's from Launchpad. [09:53] :-$ [09:57] hi [09:57] "it sounds dangerously wrong", see revno 5999, I'm not introducing that [09:57] oh, so i think your parent_branch config setting is wonky [09:58] jam: "it sounds dangerously wrong", see revno 5999, I'm not introducing that [09:58] hm, or, which branch are you trying to propose? [09:58] jam: I'm just formalizing the existing code [09:58] soren, basically what's happening is that bzr is trying to infer which branch you intend to merge into, and getting an apparently impossible path [09:58] poolie: Can you try this, please: [09:58] poolie: bzr info lp:nova [09:58] vila: that was *only* for reading *just* branch.conf to get the stacking location [09:58] Just for shits and giggles. [09:58] not *all* settings [09:59] if that's what you've done, great. [09:59] poolie: ...because I get that error doing that as well. ~soren/nova/trunk is something that only ever existed on Launchpad. [09:59] poolie: Hang on, I'll post the .bzr.log. [09:59] (we no longer support using locations.conf to override a stacked location, but we still support it for everything else) [09:59] jam: it's not used yet but the plan is to use it only for this case if that's possible [10:00] jam: and neither do we for default_stacking_on if I understand correctly [10:00] poolie: http://paste.openstack.org/show/2269/ [10:00] vila: I think you're right about default_stacking_on but I have limited experience with it. [10:00] poolie: It seems to get the ~soren/nova/trunk bit back from lp (no clue why, though) and tries to make sense of it locally. [10:00] poolie: Or rather, ../../../~soren/nova/trunk which makes even less sense to me. [10:01] jam: but thanks for the poke, I'll double-check (now that you mentioned it, I may have fall into a trap with that) [10:01] poolie: This happens even if I explicitly specify the target branch. [10:01] vila, can he fix this with bzr config to update the branch conf? [10:02] jam: which in retrospect was my main concern with revno 5999 (even if I didn't make a funny face at the time ;) [10:02] poolie: ..and with an empty locations.conf as well, apparently. [10:02] poolie: in theory yes, in practice there may be bugs with remote branches [10:02] ... they should be filed and fixed of course ;) [10:03] soren, did you perhaps rename this branch from something else to be the trunk? [10:03] soren: it is a setting in .bzr/branch/branch.conf which is saying that the "parent" branch is ../../../~soren/... [10:03] I'm not sure why we need the parent [10:03] ah, lp-propose is failing [10:03] because it is trying to auto-detect what branch you want to target [10:03] yes, that's what i said :) [10:04] jam: .bzr/branch/branch.conf: http://paste.ubuntu.com/673676/ [10:04] poolie: yeah, your statements were intermixed around when I was chatting with vila, so I missed bits [10:04] silly conversation threading [10:04] soren i think 'bzr config -d lp:nova --remove parent_location' should fix it [10:04] poolie: Nope. [10:04] poolie: I haven't referred to anything as trunk in over a year. [10:04] soren: it is the remote one that is probably the issues [10:04] issue [10:05] I'm happy to try it, but: [10:05] http://paste.ubuntu.com/673682/ [10:05] I suspect we have been propagating parent_location from local to remote branches in the past (and we may still do so) [10:05] soren: the small issue is that launchpad changed how you access branches, from always being 3-parts (~user/project/branch) to sometimes just +branch/project [10:05] There's no reference to anything called trunk. [10:05] soren: the issue is lp:nova [10:05] ~soren/nova/trunk was abandonded well over a year ago. [10:05] jam: Oh. [10:06] soren: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf [10:06] jam: That makes even less sense to me: [10:06] * vila pesters about not being able to decipher /+branch-id/362222 [10:06] http://paste.ubuntu.com/673683/ [10:06] jam: Oh, dear. [10:06] jam: That is so wrong. [10:06] soren: I'm guessing you created the branch by branching from soren all those years ago [10:07] jam: Yes, that's entirely likely. [10:07] soren: what version of bzr are you using? [10:07] Now? [10:07] Bazaar (bzr) 2.4.0 [10:08] soren: bzr config -d lp:nova "parent_location=" [10:08] I can't. [10:08] should get rid of that setting [10:08] I'm not ~hudson-openstack. [10:08] ugh [10:08] ...but I guess I could become him. [10:08] soren: we can get a sys-admin to do it if you can't [10:08] but it takes a while [10:08] * soren does so while whistling innocently. [10:09] you're asking a sysadmin? [10:09] I think he's becoming ~hudson-openstack and can't answer from there ;) [10:10] poolie: soren is doing it himself [10:10] well, at least for now [10:10] oh, really [10:10] if he comes back saying it doesn't work, i'll contact a losa [10:10] poolie: it sounds like ~hudson-openstack is a bot [10:10] (hudson and all that) [10:10] yeah [10:12] * vila scratches head... [10:12] I'm battling this right now: Unable to copy ownership from "/var/lib/jenkins/.bazaar" to "/var/lib/jenkins/.bazaar/locations.conf". You may want to set it manually. [10:12] GImme a minute. [10:13] launchpad redirects lp:nova to https://code.launchpad.net/~hudson-openstack/nova/trunk but 'bzr config -d' doen't give the same result [10:13] What does this mean for me? [10:14] uark! [10:14] http://paste.ubuntu.com/673691/ [10:14] That can't be good. [10:15] vila ^^ ? [10:15] lp-propose-merge does seem to be happier, though. [10:16] poolie: wow, that is so wrong, lp urls are not even supposed to be supported... 'lp:novalp:nova' ... is wrong too but [10:17] and bug #832653 filed anyway [10:17] Launchpad bug 832653 in Bazaar "bzr config -d lp:nova gives unexpected results" [Medium,Confirmed] https://launchpad.net/bugs/832653 [10:18] soren: what's your 'bzr config' output in the branch you ran lp-propose ? [10:19] vila: http://paste.ubuntu.com/673692/ [10:21] soren: still looks wrong here: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf [10:21] Yes, ti does. [10:21] it, even. [10:21] soren: so you're not under /home/soren/src/openstack/nova ? [10:22] vila: I am. [10:22] vila: Oh, sorry. [10:22] meh [10:22] ha [10:22] soren: sftp bazaar.launchpad.net ; cd ~hudson-openstack/nova/trunk/.bzr/branch; rm branch.conf [10:22] 10:02 < soren> poolie: ..and with an empty locations.conf as well, apparently. [10:22] vila: I cleared out locations.conf to see if that was causing it. [10:22] ha, ok, empty locations.conf was the missing bit [10:23] soren: though you can continue helping vila debug remote config issues if you want. [10:23] soren: keep in mind that locations.conf *overrides* branch.conf (but seem to act as a default value provider) [10:23] vila: Wow, really? [10:23] That's... wow. [10:23] Ok. [10:24] Is that by design? [10:24] soren: Users have access to locations.conf [10:24] but may not have access to branch.conf [10:24] How can they not have access to branch.conf? [10:24] soren: You can't write to *my* branch.conf [10:24] though you may read it when branching from me [10:24] so locations.conf was designed as a way to override settings for your personal use [10:25] but also grew globs [10:25] soren: see bug #832046 [10:25] Launchpad bug 832046 in Bazaar "needs a way to specify default values for config options by path" [High,Confirmed] https://launchpad.net/bugs/832046 [10:25] which meant that it started providing defaults as well as overrides [10:25] Fascinating. [10:25] which makes things messy [10:25] you need 3 layers, basically [10:25] Defaults, branch, overrides. [10:25] defaults get overridden by branch local config gets overriden by user specified overriedss [10:25] Right. [10:26] That lp:novalp:nova thing... Is that going to cause troupble? [10:26] Or trouble? [10:26] tyops welcome ;) [10:27] Rule 1: You always need 1 level more than you have. Rule 2: The cognitive load limit is always 1 level less than you have :p [10:27] vila: "tyops"? [10:27] vila: Oh. typos :) [10:27] well, I would be surprised if it applies to lp:nova urls anyway since urls are supposed to be translated already when dealing with locations.conf [10:27] vila: orly? [10:28] soren: yeah, I do less tyops once I invoked the tyop god [10:28] only [10:28] but it doesn't work everytime [10:28] Well, maybe this time dog will simile on you. [10:31] fullermd: smile ? [10:32] pqm might be having trouble? [10:32] i've asked the sysadmins [10:34] jam: wow, you sent https://code.launchpad.net/~vila/bzr/824513-fadatasync-options/+merge/72454 to pqm *after* I did (lp is misleading, I did the send after the push) [10:34] jam: still I didn't get any answer, did you ? [10:35] vila: I was trying to submit one of mine, I just read the proposal wrong and submitted yours [10:35] poolie: blackbox.test_branch.TestBranch.test_branch_broken_pack FAIL is spurious, dunno if we have a bug for that though [10:35] we do [10:35] yes it's broken; will be fixed soon [10:35] o/ jelmer [10:35] hey poolie :) [10:35] jam: ha, ok, still did you get an answer or is indeed pqm borken, ha right [10:36] jelmer: hey ! [10:36] can you guys re-feed them if necessary when the paper jam is cleared? [10:36] vila: I didn't get any response and the web page is "0 scripts" for me [10:36] poolie: certainly [10:36] jam: ok, same here [10:36] want us to resubmit your "trivial" as well? [10:37] yes thanks, i have two or three approved [10:37] i have 10 assigned bugs and i think all but one or two are blocked [10:40] poolie: in what channel did you ask the sysadmins? (Just trying to follow the thread) [10:42] jam: #is [10:44] #is [10:55] poolie, jelmer: Are we doing the udd standup in 5 min? [10:55] no, it's on holiday for augest [10:55] *august [10:55] ah, ok [10:55] afaik [11:10] afternoon all. [11:12] * jelmer waves to mgz [11:19] mgz: _o/ [11:21] hi mgz [11:21] * poolie fixes a package import, yay [11:28] hm, bug 832052 is interesting, if it was hit on 2.4.0 [11:28] Launchpad bug 832052 in bzr (Ubuntu) "bzr crashed with ShortReadvError in _seek_and_read(): readv() read 0 bytes rather than 174 bytes at 0 for "469df00e67f848246f876663fb299e10.rix" (dup-of: 413430)" [Undecided,New] https://launchpad.net/bugs/832052 [11:28] Launchpad bug 413430 in Bazaar "ShortReadvError on index file" [High,Confirmed] https://launchpad.net/bugs/413430 [11:28] which should have fdatasync on === nyuszika7h is now known as somebody === somebody is now known as nyuszika7h [11:49] Riddell: thanks for backporting that i18n fix! [11:49] jelmer: the rt got a reply so we should have access to PQM's 2.4 now [11:50] Riddell: that was quick === idnaria is now known as idnar === davi` is now known as Guest70489 [13:05] jam: ping [13:05] hi mgz, I was wondering when you would show up [13:05] ha, we were both waiting for each other to say something first? [13:05] I guess so [13:16] anybody object if I just turn on translations for the bzr project in launchpad? I don't see a reason why not [13:16] Riddell: +1 (I thought it has been done :-/) [13:17] Riddell: go for it [13:17] Riddell: what series will be impacted ? [13:17] that's the next question, do we want to point people at 2.4 or trunk [13:17] Riddell: perhaps have it export to a different branch rather than directly to trunk [13:18] Riddell: does 2.4 have enough support for translations for translations to actually be usable? [13:18] Riddell: if there is a way to point to trunk-only first that will allow us to debug the fallouts [13:19] jelmer: yes, for most of the command help text [13:19] jelmer: only command helps IIRC, so testable but not that useful [13:19] I'd prefer targetting trunk in that case; we don't know what other fallout there may be from translations [13:30] jelmer: what's your worry about exporting to trunk? [13:41]