[00:00] cjwatson: How are we going to produce the C translations files? [00:00] (also, your LongDescription interpretation is inverted, AFAICS) [00:00] C as opposed to en? [00:00] Well, do we produce the ones it's going to look for by default? [00:02] inverted> oh bugger, you're right, silly inscrutable docs === sidnei_ is now known as sidnei [00:08] apt-ftparchive defaults to writing to Translation-en, and mvo told me he'd just stop uploading -en in the i18n custom uploads. But perhaps it ought to be C, or perhaps the client ought to be a bit smarter here ... [00:09] Note that it is currently not possible to create these files with apt-ftparchive. [00:09] From the manpage. [00:09] Not in my version [00:10] Ahem. I was looking at carob accidentally. [00:10] Indeed, natty's is a bit more encouraging. [00:11] hmm. I wonder if this is going to need YA lucid backport though ... [00:12] That stuff should be somewhat self-contained, if we want to convince mvo to backport the patch... [00:12] I'll discuss the question of using Translation-C with mvo. At worst it would just be a matter of setting TreeDefault::Translation / Tree::blah::Translation [00:13] backporting the patch will happen [00:13] both mvo's manager and his tech lead want this :-) [00:13] Heh [00:13] Useful. [00:14] I'll fix the inversion. Should I rename the database column as well? I kind of like having the new column be False by default, though [00:15] so split_long_descriptions True => LongDescription "false" [00:15] I'm not sure. Possibly include_long_descriptions defaulting to True would work... [00:15] Hmmm [00:16] oh, there's default= in Bool [00:17] I'm OK with that if it seems less confusing [00:17] anything else from a first pass that I should sort out? [00:19] cjwatson: Looks reasonable. [00:25] Cool, thanks. I'll work on that tomorrow then [00:25] Great! [00:29] wallyworld_: Is your last comment in bug #803996 a regresion on qastaging? [00:29] <_mup_> Bug #803996: person picker widget doesn't show link to unassign myself

< https://launchpad.net/bugs/803996 > [00:29] wgrant: not sure if it's a regression [00:30] but it pertains to that bug so i added it as a comment to ensure the full scope of the issue was fixed [01:02] StevenK: How goes the vocab? [01:09] wgrant: *RARGH* [01:10] As expected! [01:13] wallyworld_: should it hold up deploying? [01:14] lifeless: not imho. it's a minor usability issue (page refresh fixes it) and i'm not even sure it's a regression [01:14] i just noticed it doing some unrelated qa [01:14] wallyworld_: then you might like to file a new bug for it, to fit the qa process [01:15] lifeless: there's a bug already. i just augmented the bug details to provide extra info [01:15] wallyworld_: but its the bug that will be closed when we deploy on thursday [01:16] wallyworld_: if you land another incremental branch for it between now and then, we'll be unable to qa it, and the downtime deploy will get more hairy [01:16] lifeless: ? the bug is associated with a kanban card that is in the todo list [01:16] and... we're qa-bad for it now [01:16] rev 13392 is broken [01:17] I thought it would be. [01:17] But where? [01:17] compare https://launchpad.net/~launchpad-dev/+members and https://qastaging.launchpad.net/~launchpad-dev/+members and then click next in both on the 'active member' batch [01:17] lifeless: bug 803996 is only triaged. that's the one i added the extra info for based on by observations when playing with qas [01:17] <_mup_> Bug #803996: person picker widget doesn't show link to unassign myself

< https://launchpad.net/bugs/803996 > [01:18] lifeless: Ah, indeed. [01:18] wallyworld_: ah, cool [01:18] wallyworld_: sorry for my confusion [01:18] lifeless: np. it was well worh the question [01:18] worth [01:18] wgrant: the memo is not being adapted, so the memo for nav A is affecting the content for nav B [01:18] Yup. [01:19] frell [01:19] Revert or fix? [01:19] revert [01:19] I think revert. [01:19] Yeah. [01:19] unknown number of instances [01:19] wgrant: how would you feel if I asked you to do the honours ? [01:20] I've been chasing emails and stuff so far today - I only just got to doing qa on this [01:20] Like I've done that a bit too much in the last week, but okay. [01:20] * wgrant does it. [01:20] I will dig up the MP and explain the situation on it === mwhudson__ is now known as mwhudson [01:21] I have 6 reversion branches in ~/launchpad/lp-branches :( [01:21] :( conflicts [01:21] in a .txt file [01:22] Yeah [01:22] Which is merged. [01:22] its shallow - just keep the trunk version [01:22] the change was from explicit url to ... [01:22] but oh the pain - if it makes your eyes bleed, I will do it [01:23] hmm [01:23] the alternative is to not back this out [01:23] lets talk through it for a second: [01:24] - for any given navigator, it will work to navigate it as long as you don't switch navigators half way through things [01:24] - multi-navigator pages are the exception [01:24] - and switching should be rarer still [01:24] But if we revert now, we can deploy it on Friday and be able to easily revert if something goes wrong. [01:24] so, what about filing a critical and rolling forward [01:25] This change is scary and hard to verify completely. [01:26] there may be other unintended side effects [01:27] or this one may go deeper than thought [01:27] We lose little by reverting it now. [01:27] We gain flexibility. [01:28] And, given the mess that the last 1.5 weeks have been, I think that is a good thing. [01:29] I'm not worried about it landing later [01:29] I was thinking about the headache of the reversion branch [01:29] thats all [01:30] wgrant: how fugly does the reversion look ? [01:30] Not very. Just running the tests now. [01:32] so bug batches look fine [01:32] though 'Last' still times out (because the order reversing stuff is not yet hooked up to any lp batches) [01:47] lifeless: Shall I land the revert? [01:48] wgrant: it was fairly clean? if so yes. [01:49] !2 [01:49] I just --take-other on the story, and it passes fine. [01:52] * wgrant lands. [01:54] Bah, forgot r-c === lifeless changed the topic of #launchpad-dev to: devel in RC until r13403 deployable | Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 220 - 0:[######=_]:256 [02:14] 220? [02:14] :( [02:18] jtv: this may be fallout from red's current work - https://bugs.launchpad.net/launchpad/+bug/808950 [02:18] <_mup_> Bug #808950: DistroSeries:EntryResource:searchTasks AssertionError: wrong You exported name as an IChoice based on an SQLObjectVocabularyBase, you should use lazr.restful.fields.ReferenceChoice instead < https://launchpad.net/bugs/808950 > [02:19] jtv: I don't know if it is|isn't [02:21] mpt: hi [02:22] mpt: how would you feel if your transcribed talk was edited - treated as a live doc? E.g. where you give the example of having the word 'should', I would like to add 'add', 'remove', 'change', and perhaps more as other 'words to be wary of' === wgrant changed the topic of #launchpad-dev to: devel in RC until r13405 deployable | Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: wgrant | Critical bugs: 220 - 0:[######=_]:256 [02:51] wallyworld_: Around? [03:09] lifeless: Can I add X-Lazr-OopsId headers to webapp OOPSes too? [03:10] (to display less useless errors when pickers fail) [03:11] wgrant: can you rename it? [03:11] The other one is set in lazr.restful, I believe. [03:11] wgrant: X-LP-OOPSID everywhere would make me happy. [03:12] Sadly I guess clients may depend on it. [03:12] And it is not overridable without lazr.restful changes. [03:15] so there are I guess 3 q's [03:15] can we add a header: absolutely [03:15] should it be the same as the API one? I dunno [03:15] does the name matter? not really, but X-LP-OOPSID is or even X-OOPSID would be a lot better [03:17] wgrant: you could add whatever name and rename it later [03:17] wgrant: I don't mean to inflae the work you have to do [03:21] Grar [03:21] I hate Soyuz. [03:22] Stop deleting evidence. [03:24] no sequitur ? [03:25] Yes [03:25] Soyuz will let you delete a publication multiple times. [03:25] Each attempt will overwrite the last date. [03:25] So I can't see what this user actually did to break their archive. [03:33] https://dev.launchpad.net/LEP/FastDowntime for those liking 'agile' [03:35] yay [03:35] indeed [03:44] poolie_: I'm pretty sure both frontends are broken mimetype-wise. [03:44] poolie_: But not all of them have the bad data cached all the time. [03:44] I've seen text/html from both. [03:44] stub: hiya [03:44] Hi [03:45] poolie_: Indeed, there are logs in the bug to show it happening from both. [03:46] stub: I'm just filing bugs for fastdowntime at the moment [03:46] Cool. [03:46] stub: Thanks for landing batchnav! however we've had to roll it back - found a corner case [03:46] when we have two navs on one page the new variables need their name mangled [03:47] I think the pgbouncer config on prod is setup, but waiting on pgbouncer installation on sourcherry to proceed. Silly losas think testing is a good thing or something! [03:47] mad buggers [03:47] spm: can we get it on sourcherry then ? [03:47] We have 2 batchnavs on one page? [03:47] stub: yeah - e.g. ~launchpad-dev/+members [03:47] last I heard the rt was with stephan [03:48] so its an easy fix, I commented in the MP [03:48] wgrant, oh i see [03:48] stub: installed [03:49] that is easier to explain than having persistently different behaviour between what should be identical machines [03:49] spm: And permissions on /etc/pgbouncer contents set so I can configure it? [03:49] i assume at this stage we're not pulling pgbouncer into the lp-db-deps? [03:49] poolie_: Yes. :/ [03:50] Perhaps we should go poking in squid caches or logs or something. [03:50] spm: No. Maybe one day if the rollout script is tested with out test suite in the -dev packages. [03:50] oki [03:50] bbiab [03:50] normally we object violently to 'install package' unless it's in the meta, but I'll let this ride for once. [03:50] where violently == 4x2. [03:50] wgrant, in that case it actually is a dupe [03:50] where violently == 4x2/ip [03:51] poolie_: I've already fixed that up :) [03:51] thanks [03:51] spm: I'm not fussed, but we will only need it installed on at most two machines so similar to haproxy. [03:51] it occurred to me it would be interesting to have a losa look directly at the backend and see what it answers [03:51] (+staging) [03:51] presumably always the correct thing [03:51] poolie_: We've never seen the backend return bad data. [03:51] poolie_: But it possibly only does it in response to certain request headers. [03:52] stub: have at it [03:52] how would you know if the backend returned bad data? [03:53] poolie_: With manual testing, this is. [03:53] iow what i said has already been tried? [03:53] stub: I'm not sure of your meaning wrt machines similar to haproxy, wrt staging? [03:53] poolie_: Yes. [03:54] spm: At most, we want pgbouncer running on two production machines + staging, similar to our HAProxy dependency. So putting it in the -db meta package didn't occur to me. [03:56] Probably more a puppet thing since it one package + several customized configs [03:56] oh I see. right. [03:58] whats the name of the codebrowse url mapper thingy? [03:58] lifeless: Are you expecting me to sort the batch navigator branch or is it punted to a bugs team? [03:59] lifeless: branch-rewrite [03:59] stub: Its in limbo [03:59] stub: a bugs team working on batch related timeouts would have motivation to do it === poolie_ is now known as poolie [03:59] stub: if you want to do it, be my guest; not expecting you to do so (or not to do so) [04:00] lifeless: It is a dependency of a bug abel is assignedl [04:00] I'll checkout the required work after breakfast. [04:00] stub: I think abel should do it then, it should be pretty easy. [04:01] but sure, EIDONTCARE :) [04:02] I'm going to pull out our reliance of transaction-persistent cursors from garbo.py so we can run pgbouncer in transaction mode rather than session mode. [04:03] Which is a bit sucky, as I thought that code was rather cool ;) [04:03] Think I'll need to replace it with two connections to remain efficient. [04:04] stub: it was cool, but I totally endorse that change [04:06] stub: could we do a brief voice call ? [04:07] stub: I want to check I didn't miss anything for round one of fast downtime [04:07] Sure. I'll just plug stuff in. [04:16] https://dev.launchpad.net/LEP/FastDowntime [04:40] wgrant: has lazr.amqp had its non-longpoll expunged? ready for rename ? [04:41] lifeless: It hasn't. [04:42] I might look at that this afternoon. [04:42] bug 809132 [04:42] <_mup_> Bug #809132: lazr.amqp is overly broad < https://launchpad.net/bugs/809132 > === Ursinha is now known as Ursinha-afk [04:56] wgrant: hi. i had to go out and sort out some car issues :-( back now [04:58] wallyworld_: Was wondering how to mock out HTTP requests in the picker for unit testing. [04:58] wgrant: we have about 3 different Y.io mocks [04:59] the bugs js uses one style [04:59] I saw MockIo, but it's only used in one place. [04:59] Seems to be from lazr-js. [04:59] there's also mickio.js brought across from lazr-js [05:00] in other places, a js object is constructed with just the method (eg patch) that is to be patched implemented [05:00] in most cases, the mock io object is passed to the js business logic [05:00] pickerpatcher uses Y.io directly. [05:00] I want to test the handling of errors. [05:00] yes, see ^^^ [05:00] Ah [05:01] the most common approach seems to be to pass an optional io object to the business lgoic [05:01] if io===undefined, use Y.io [05:01] else use the mock [05:01] there's implementations in out code base that allow the expected api call to be chacked and a return result to be provided [05:02] if you search for IOStub you'll see some examples [05:02] but I'd rather get a good, reusable implentation into our testing framework [05:02] and have everything use that [05:02] wgrant: where is longpoll deployment at? [05:03] lifeless: Yes. [05:03] would a bug be helpful ? [05:03] * lifeless makes one [05:04] Possibly. [05:07] wgrant, huh, well spotted with the 304 [05:07] that's pretty perverse [05:07] does it give you a body, or just the header? [05:08] poolie: lifeless did the real diagnosis :) [05:08] It just gives the header. [05:09] ok, ciao [05:15] Well, that lazr.amqp pruning was easy. [05:15] poolie, hi! [05:16] hi sidnei [05:17] poolie, i had a question about branch splitting earlier, not sure you saw it [05:18] hi [05:18] there is 'bzr split' [05:18] wgrant, couldn't it just not give a content-type header? [05:20] poolie: Possibly very true. [05:20] poolie, so after splitting a directory from the tree, does it get removed from the original tree or does that need to be done manually? [05:21] "Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body." [05:21] poolie: So, looks like we can omit it. [05:21] Particularly since we have no entity-body. [05:21] grarr [05:21] Just ran into this bug when trying to build lazr.amqp :( [05:23] Blah. [05:23] right [05:23] i thought it was normally omitted [05:23] twisted.web.server.Request.process sets it to text/html at the start of the request :/ [05:23] So we'd need to delete it... [05:23] sidnei, you will then have one tree with the subdirectory excised, and underneath it another checkout with that tree present [05:23] hm that's a bit presumtuous [05:24] i guess it depends if you want to fix this in twisted or to work around it [05:24] Would be nice to fix it in Twisted, but not sure how to do that in a backwards-compatible manner. [05:25] Or we could just declare the existing behaviour broken. [05:25] Perhaps. [05:25] 304 could perhaps just squash the ct [05:25] Indeed. [05:25] it seems unlikely anyone would really want that behaviour [05:25] Probably a good idea. [05:28] A self.responseHeaders.setRawHeaders("content-type", []) after the self.setResponseCode(NOT_MODIFIED) seems to work sensibly. [05:28] Is a little ew, though. [05:29] twisted was designed with POMA in mind (as opposed to POLA - http://en.wikipedia.org/wiki/Principle_of_least_astonishment) [05:29] Heh [05:30] sidnei, anyhow i suggest you at least try split [05:30] what are you going to want to do with these branches in future? [05:31] wgrant, it should possibly be more general than just c-t and 304 but ... [05:31] this would be the main case i guess [05:32] poolie, https://bugs.launchpad.net/graphite/+bug/501828 [05:32] <_mup_> Bug #501828: Create separate branches for the webapp, carbon, and whisper < https://launchpad.net/bugs/501828 > [05:34] poolie, which, btw, is still using pack-0.92. guess it's time for upgrade :) [05:36] * wgrant stabs buildout in the eye. [05:36] FASTER [05:37] Haha [05:38] lifeless: txamqplongpoll, maybe? [05:51] wgrant: sure [05:51] though txlongpoll is a bit snappier [05:51] lifeless: It is, but it's also more generic. [05:52] Although possibly reasonable. [05:53] txhttpamqp ? [05:54] That's even more syllables. [05:54] Perhaps we should just do txlongpoll, as you say. [06:19] Hmm. [06:20] Maybe we should just run txlongpoll from a package. [06:20] Since all its runtime deps are in main. [06:21] Hm, no, python-txamqp is not in main, but it's in some PPA I have, but I can't think which. [06:21] s/have/had/ [06:21] Must have been u1 or something. [06:29] wgrant: no, because we can't sanely upgrade from packages (now, if ever) [06:29] Bah. [06:30] danilos: bmp-inline-diffs has the wrong cursor for the expander link... it looks to me like perhaps the CSS needs to be adjusted so that .expander-node.js-action has the cursor:pointer style, or something like that? [06:30] danilos: or is there something my branch is missing? [06:33] wgrant: we need to address that eventually, but I'd rather not put 'fix python packaging upstream' in our criticalpath [06:34] wgrant: btw, has your revert landed ? [06:35] lifeless: It passed buildbot 10 minutes ago. [06:35] how are we on assessing 13391 [06:36] An indeterminate point between "handwave" and "kill me now" [06:38] Ah. [06:38] It says "Remove Person", when it shouldn't be talking about removing people and should be sentence case. [06:38] I don't trust it any more. [06:38] Tempting to revert. [06:38] page? [06:40] Any person chooser on a traditional form. eg. the bug supervisor field on https://launchpad.net/launchpad/+configure-bugtracker [06:40] Or assignee on +filebug [06:40] wallyworld_: ^ is that intentional ? [06:41] i think so [06:41] Sentence case looks and is wrong. [06:41] "remove person" is a bit violent. [06:41] But it seems to mostly work. [06:41] it's config - it can be changed [06:41] Person is wrong too [06:41] s/Sentence/Title/ [06:41] (teams are not people outside of LP's schema :)) [06:42] it should say Remove Assignee for bug task pickers and whatever the default text is elesewhere (unless overridden) [06:43] so i guess the default text is wrong plus some overrides are required [06:43] oh, there is a regression [06:43] I've just been reading the code so far. [06:43] on https://qastaging.launchpad.net/launchpad/+configure-bugtracker [06:43] What's the regression? [06:43] go to the bottom - e.g. security contact [06:43] click on 'Choose...' [06:43] Hm. [06:43] If you reopen it goes away. [06:43] then click on the search widget (don't change the text) [06:43] now try to remove the assignee [06:44] however the regression is live on prod already [06:44] so its not a new problem [06:44] ah, except [06:44] on prod if you reopen the picker [06:44] you get the buttons back to remove assignee etc [06:45] I have to run - can you two - wallyworld_ , wgrant - decide if this is really a regression or not, and revert or file a bug accordingly? cheers, [06:45] * lifeless goes [06:45] that issue i am looking at now - the remove/pick me buttons not reappearing after a search [06:45] it's not a regression [06:45] wallyworld_: They also don't appear if you reopen the picker while the textbox is empty, AFAICT. [06:45] It is very odd. [06:46] they won't appear if a search has been done [06:46] So, the UI text is pretty bad and needs fixing, but rolling back is expensive... [06:46] it's not a regression, so rolling back won't help [06:47] the issue was present in the original work john did afaict [06:47] Which isn't a regression? [06:47] the buttons disappearing [06:48] after a search [06:48] Ah. [06:48] i have a simple fix for the disappearing buttons issue but writing a test is a bitch [06:48] without any io stubs :-( [06:48] the wrong Remove Person text is also not a regression [06:48] i can'r recall when that branch landed [06:49] It's currently "Remove assignee" on production. [06:49] Which is correctly capitalised, and only questionably worded, not outright wrong :) [06:49] Removee assignee everywhere? [06:49] Yes. [06:49] https://launchpad.net/launchpad/+configure-bugtracker [06:50] ok. the branch that changed the wording was done to address a bug that said "Remove assignee" was wrong [06:50] It's less than ideal. [06:50] so it's wrong differently [06:50] But "Remove Person" is doubly wrong. [06:51] don't be a case nazi :-). we can live with "incorrect" case, no? [06:51] It is terribly ugly. [06:51] it's just the use of the word Person in cases where it's a team? [06:51] That too. [06:51] beauty is in the eye of the beholder [06:51] i honestly can't see why this is such a showstopper [06:52] it's easily fixed i'm sure [06:52] Because I don't trust the branch and am looking for excuses to revert it. [06:52] why don't you trust the branch? [06:53] besides cosmetics, is there anything *functionally* wrong? [06:54] Because I've had to revert it once already, along with 6 other things in the last week, it uses string concatenation to create HTML, the text is wrong, there are underlying bugs with the previous branch that aren't yet resolved, suggesting everything is more fragile than we can imagine... [06:55] there was one reverted due to a true/True issue but this is a different branch now afaik. the concat and etc and text don't warrent a rollback. they can be fixed [06:56] This is a relanding of the true/True issue branch. [06:56] not exactly - it also has other stuff in there if i am correct [06:57] Sure. [06:57] But it is a superset of the branch that was rolled back. [06:57] + fixes [06:57] yes, believe so [06:58] so we have 3 outward facing issues - text, wording and the disappearing buttons issue. [06:58] disappearing buttons i have a fix for but need to figure out what effort i should expend writing the %@^!$ test without a io stub [06:59] the text case is ugly but cosmetic [06:59] the wording is unfortunate and we can land a fix quickly [06:59] (three *known* outward facing issues, but OK) [07:00] i don't think any others have come up so far? [07:00] Right, so any other problems are as-yet unknown. [07:00] there's only a finite number of use caases to check [07:00] lol [07:00] where finite is not that large [07:01] i mean in terms of how pickers are wired up [07:02] rather than actual instances on all lp pages [07:26] lifeless: hi. That API bug you ran into looks like a Bugs problem, not apparently related to our derivation work. [07:32] jtv: You haven't been playing with distroseries vocabs at all? [07:33]