[00:05] wgrant: http://bazaar.qastaging.launchpad.net/~launchpad-pqm/launchpad/devel/files looks okay to my testing, but I'm not sure how to stress it [00:09] StevenK: Have you tried some non-ASCII paths? [00:11] That means finding a branch that happens to have some, or making my own... [00:20] danilos: Are bug #869264 and bug #730610 duplicates? [00:20] <_mup_> Bug #869264: Old upstream translations overwrite newer upstream translations in Ubuntu

< https://launchpad.net/bugs/869264 > [00:20] <_mup_> Bug #730610: translation uploads from old series replace the current series translations < https://launchpad.net/bugs/730610 > [00:23] wgrant: http://bazaar.qastaging.launchpad.net/~stevenk/+junk/foo/files [00:24] StevenK: Does that crash on prod? [00:24] Nope [00:25] Then it's not a dreadfully good testcas [00:25] e [00:26] It's in a dirname function [00:26] So it will probably need to be a directory name [00:27] Yes, I'm pushing r2 now [00:28] http://bazaar.launchpad.net/~stevenk/+junk/foo/files/head:/foo%C7%80%C6%B6/foo%C6%86/ => OOPS [00:28] * StevenK reaches for qas [00:28] wgrant: OOPS-3b6ba4d894000fb4d96e6e6e947ef2cd on prod, a lack of oops on qas [00:28] StevenK: Marvellous [00:29] Does it look sane on qas? [00:29] Yes [00:29] So it does [00:29] wgrant: http://bazaar.qastaging.launchpad.net/~stevenk/+junk/foo/files [00:29] qa-ok! [00:29] wgrant: Does sir wish for a NDT? [00:29] Indeedily. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [03:45] Ahhh [03:45] Tracked down the translation consistency bug finally [03:45] The export bug [03:45] czajkowski: ^^ [03:57] wgrant: Oh? [04:00] StevenK: Filtering a left join in the wrong place [04:00] Similar to a mailing list bug we had a couple of years ago [04:00] Handy [04:00] And sort of subtle without tests [04:01] Yeah [04:02] It excludes messages when the potmsgset is shared, and the only translation is a diverged one for the other side. [04:35] jtv: Around? [04:35] Hi wgrant [04:35] I mean: yes. [04:35] jtv: Hi [04:36] jtv: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/translations/doc/vpoexport.txt#L101 [04:36] The last section [04:36] I think the test is insane [04:36] Do you remember enough about this to sanity check it? [04:36] The test asserts that the untranslated messages aren't returned by getTranslationRows [04:37] But normal untranslated messages *are* returned [04:37] Im looking. [04:37] The ones in this test are not returned due to a probably SQL bug which excludes messages if the only translation is a diverged one on the other side [04:37] Oh, by the way: it's a doctest, so safe assumption that it's insane. [04:37] If I were to create a new template item, it would show up there [04:37] Hhe [04:37] Yes [04:38] Excludes messages from what? From the list of suggestions? Or from the translation? [04:38] Because if the only translation is a diverged one on the other side, that means there's no translation where you're looking. [04:38] getTranslationRows is used for PO exports, so it's meant to return all of the template's messages [04:38] Even if they're untranslated [04:39] It achieves this, except that the left join condition is in the wrong place, so if the only translation for a potmsgset is a diverged translation for another template, the message doesn't show up at all, even with a null translation. [04:39] Oh, the potmsgset is being left out? [04:39] Gotcha. [04:39] The test asserts that behaviour; both of those examples at the end should also return a None row AFAICT [04:41] Let me just look closer into what getTranslationRows was meant to do... [04:41] Sure [04:42] https://pastebin.canonical.com/87982/ [04:42] If I add a third message with no translations at all, it shows up, as I assume the correct behaviour is [04:42] #@$ 2fa [04:43] But the messages that have only diverged translations don't show up at all. [04:43] http://paste.ubuntu.com/5654235/ [04:43] Trying to load that first pastebin first. [04:43] The second one is the same [04:43] But no 2FA :) [04:43] Ah [04:43] I'll have a look. [04:46] Why, why, why did nobody accept my proposal of using null instead of 0 as a sequence number for obsolete messages? [04:46] I have been wondering that for a good portion of the last week [04:46] I hoped you'd have an excuse :P [04:47] Well okay, I think I remember the reason: it was left for later. [04:48] Heh [04:48] I guess the condition on TranslationMessage.potemplate is in the wrong place, yeah. [04:48] Yeah [04:48] If I move it into the left join where it should be, the bug goes away and that test fails [04:49] Watch out for performance changes. [04:49] (Even if it gets faster, I'd like to hear about it :) [04:49] There's also the slightly confusing aspect that in its current position it's actually a three-way disjunction: no TM, undiverged TM, or diverged TM for this template [04:49] Yeah [04:49] The existing query is absolutely dreadful, so I'm not too concerned [04:49] But I will check [04:50] Oh [04:50] The query itself is only a couple of seconds [04:50] I guess the data transfer and object loading may be big [04:50] 'cause it appears to take about a minute [04:50] When run in a harness [04:50] FWIW VPOExport used to be a view in the database. Meant as an optimization, had turned into maintenance *and* performance drag. [04:51] A minute in harness? What kind of dataset are you running against!? [04:51] ddtp-ubuntu-universe [04:51] Ah OK then :) [04:51] aka. the biggest template [04:51] It's what the bug was reported against [04:51] And I had no idea what was wrong [04:51] So couldn't really minimise it [04:51] Any major speed changes for that query though? [04:51] Checking [04:51] Congratulations on spotting this. Good sleuthing. [04:52] And wgrant has spent 1.5 weeks with his head in rosetta :-( [04:52] (the export of just the French raring translation takes upwards of 5 minutes, so testing without a harness is a bit painful...) [04:52] Gah [04:52] StevenK: This bug is only today, though [04:52] So many things I would still have loved to have time to clean up... [04:52] Import approvals in particular! [04:52] jtv: Like lp.translations.model.* ? :-) [04:52] Pretty much. [04:53] The trick with these things is that you have to hate complexity, ambiguity, and tech debt. Seek it out & destroy it. [04:54] Oh, and you want my guess as to why data transfer & object loading seem to take so long? [04:54] Oh [04:54] It's grabbing context etc. [04:55] If the query includes POTemplate or POFile, those have text fields containing the headers. [04:55] So lots of reasonably sized strings, I suppose [04:55] Unreasonably sized header strings. [04:55] And pomsgids [04:55] Unicode conversion, awkward data sizes. [04:55] No POTemplates or POFiles here [04:55] Oh that's a relief. [04:55] Just POTMsgSets and POMsgIDs [04:55] But still not small, especially for that template [04:55] pomsgids are short and de-duped. [04:55] Descriptions are fat [04:55] Ah true [04:56] But they should only come in at the end, basically. [04:56] This template is about the worst possible case for everything, except that it has no plurals. [04:56] Quite. [04:56] Anyway, thanks for your help [04:56] :) [04:56] No worries. [05:25] StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1158854/+merge/155892 [05:33] wgrant: r=me [05:33] Thanks [05:33] I'd like Stormification, but not now [05:34] Translations is difficult to Stormify due to the dynamic column names [06:45] Oh hey, jtv is still around! ;) [06:46] Yup. Hi nigelb! [06:46] How's life? [06:46] Pretty good! Surving. How about you? [06:46] *Surviving [06:47] Are you still out East? [06:48] Yup. [06:48] Hot here. [06:48] Here too. 35C is *not* pleasant. [06:59] It hit 32 in Sydney today [07:00] I'm on the top floor of this building. Sometimes I end up sitting on the floor because it's slightly less warmer. [07:05] I've got a fan blowing at me right now. [07:06] wgrant, yeah, they seem to be describing the same thing, though 869264 is a bit more specific [07:07] danilos: Yeah, I was going to dupe them in that direction [07:07] Since 869264 is clearer [07:08] Thanks [08:31] wgrant: StevenK translation bug all fixed ? [08:32] czajkowski: Not on production yet, but the missing string thing is fixed in trunk [08:32] Will be deployed Tue or Wed [08:33] That's the two bugs from the 23rd [08:34] excellent [08:34] thanks folks === Nigel_ is now known as G === benji___ is now known as benji === teknico is now known as teknico_away === wedgwood_away is now known as wedgwood === jamestunnicliff_ is now known as jamestunnicliffe === vednis_ is now known as mars === matsubara_ is now known as matsubara === Ursinha-afk is now known as Ursula === wedgwood is now known as wedgwood_away