[00:01] huwshimi: lp:~wgrant/launchpad/the-one-domain isn't perfect yet, but it's 90% done. [00:02] wgrant: Dude, that's fantastic! [00:03] A few links still lead to the wrong place, but it pretty much works. [00:04] wgrant: That's really awesome. Did you manage to solve breadcrumb stuff? [00:05] huwshimi: Yeah, that all works. [00:05] wgrant: :D [00:05] Inline help needed a bit of a rework too, but I'll hopefully land that and the breadcrumb stuff in the next day or two, as it's an improvement even if we don't go for one-domain-to-rule-them-all soon. [00:07] awesome [00:13] wgrant: It's so nice browsing through the facets with the urls like that [00:14] I just used the existing view names. some like +specs probably want to be renamed. [00:15] And we probably want to get rid of +bugs-index [00:15] (that's the crippled version of +bugs which only shows the top 10 bugs by heat) [00:15] Isn't that used by a projects page? [00:15] wgrant: Yeah, but a great start [00:16] StevenK: Yes, but it is pointless and there was discussion last week that it might be removed. [00:23] lifeless, incidentally it looks like at least in dev, memcached is used for comment rendering still [00:24] yes, if the flag is off [00:57] Rargh, why is creating a view raising LostObjectError [00:57] StevenK: O_o have you been aborting transactions or something? [00:57] Certainly not. [01:06] * lifeless stabitty stabitty openidloginview [01:11] wgrant: can I nab you for a minute [01:12] lifeless: Sure [01:12] skype? [01:12] sec [01:12] want to get this openid fail fixed [01:16] wgrant: e.g. https://launchpad.dev/%7Emario-sitz/+archive/ppa/+login?field%85ries_filter=lucid [01:23] wgrant: there? [01:31] wgrant: hahahahahahahahahahahahahahahaa [01:32] Oh god. [01:32] What now? [01:32] eggs/zope.publisher-3.12.0-py2.6.egg/zope/publisher/http.py line 522 [01:33] lifeless: That doesn't sound particularly relevant here. [01:33] It's the query string we really care about. [01:33] wgrant: the old code before the 6* bug was fixed called getURL [01:33] wgrant: anyhow [01:46] wgrant: yes, its broken [01:46] AssertionError: 'key%3Dvalue%85' not in 'http://launchpad.dev/+openid-callback?starting_url=http%3A%2F%2F127.0.0.1%3Fkey%3Dvalue%26%23x2026%3B' [01:46] wgrant: thats using a not-unicode-at-all value in the current code [01:46] Hah [01:46] note the x2026 [01:47] entity escaping [01:47] Yeah. [01:47] this brings back horrible memories [01:49] mwhudson: indeed [01:49] mod_rewrite isn't involved is it? [01:49] mwhudson: now [01:49] Not this time. [01:50] mwhudson: no, just some dubious code in the openid login view [01:50] oh good [01:50] mwhudson: see the form_args property in login.py [01:50] mwhudson: and see if you can spot the two separate defects [01:50] mind you doing, string ops on urls unless you are exceedingly careful about normalization is ... a bad idea, i guess [01:52] indeed [01:52] I keep meaning to write a stringlike url class [01:52] that will refuse unsafe things and not be horribly slow [01:52] then I realise I have useful things to do [01:52] lifeless: well, i don't know what UnicodeDammit does [01:53] and well yeah, no escaping? i don't know enough about request.form.items() to be specific [01:53] It's good for screen-scraping. [01:53] It's not good for this. [01:53] e.g. if value_list_item was 'a&b=c' this could obviously be hilarious [01:54] mwhudson: as is a&b=c\x85 [01:54] mwhudson: thats bug one - unicodedammit does entity escaping [02:27] ok, time for zope esoterica [02:27] whats teh difference between request.items() and request.form.items() ? [02:34] lifeless: request.items() includes cookies, environ and form. [02:41] Aha [02:41] Just caught an ec2 run with the poppy error before it finished. [02:41] * wgrant investigates. [02:41] There's already a poppy-sftp running. Something's not cleaning up. [02:43] It's lp.poppy.tests.test_poppy.TestPoppy.test_bad_gpg_on_changesfile(ftp) [02:44] well, thats something we have prod issues with [02:44] \o/ [02:52] Baaaaaaaaaaah [02:52] Does ec2 shut down if it sees the testrunner hung? [02:52] I thought it just shut down after 8 hours or something. [03:02] StevenK: the BPPH.bpn populator is done. [03:03] It's not very easily noticed in the logs, since it basically blocks, blocks, blocks, and then gets killed. [03:07] wgrant: up for a review of what we discussed earlier ? [03:11] lifeless: Sure [03:11] diff soon I expect - https://code.launchpad.net/~lifeless/launchpad/oops-polish/+merge/83544 [03:11] * wgrant is looking for a reviewer for https://code.launchpad.net/~wgrant/launchpad/globalise-help-folder/+merge/83543 [03:13] Got enough criticals linked to that? [03:13] Oh, it's the old branch, I see. [03:13] yeah [03:13] it crept [03:13] Woot === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 299 [03:13] I didn't realise I was working on the wrong thing initially [03:13] * wgrant finds another OOPS [03:13] There must be one here somewhere... [03:14] Tempting to make bug #890976 critical, as it hinders determination of timeout causes. [03:14] And it would make 300 tasks. [03:15] Which is an important milestone. [03:15] bug 890976 [03:15] enomup [03:15] Bug #890976: hard to determine causes of late evaluation [03:15] its fixed ;) [03:15] Bah. [03:15] That's not very useful, then. [03:16] dunno why it wasn't marked f-r when deployed [03:17] lifeless: Anyway, I'm looking at your branch and trying to break it. [03:18] thanks [03:19] O [03:19] h [03:19] A new critical [03:19] Where'd that come from... === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 300 [03:19] victory [03:20] Ah, it was you. [03:21] timeout errors apprpving your MP [03:21] Awesome. [03:21] BranchRevision? [03:21] no OOPS reported [03:21] Or Branch FKs/ [03:21] Pardon? [03:21] 502s, then? [03:21] just a just popup saying 'timeout error' [03:21] oh [03:21] heh [03:22] OOPS ID should be in the top right AJAX log thingy. [03:22] no [03:22] Lies. [03:22] ID: 0, status: 503 (Service Unavailable) [03:22] Hmmmm. [03:22] Oddity. [03:22] ENOTLYING [03:22] Liar. [03:22] I wonder if its OOPS matching breaks with the new scheme. [03:22] But surely not. [03:22] IIRC it just checks X-Lazr-OopsId [03:22] case sensitive ? [03:23] No idea. [03:23] Anyway. [03:24] Keep trying, I guess. If it works, no problem. If it keeps timing out, it will appear on the OOPS reports where it will be summarily ignored. [03:24] :) [03:25] lifeless: You'll be pleased to know that the URL in https://bugs.launchpad.net/launchpad/+bug/61171 now causes a post-login OOPS. [03:25] good :) [03:25] s@/bugs/@/firefox/@ to make it mostly work. [03:25] Why? [03:25] closer to the right place [03:26] Heh [03:26] Looks relatively sane otherwise. [03:27] wgrant: doesn't oops for me [03:27] wgrant: it just does a 404 error [03:27] lifeless: /bugs/+filebug doesn't exist any more. [03:27] wgrant: (a 404 same-domain oops that is) [03:27] Use eg. /firefox/+filebug instead [03:27] Module zope.app.form.browser.widget, line 522, in renderTag [03:27] attr_list.append(u'%s=%s' % (key, quoteattr(unicode(value)))) [03:27] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 79: ordinal not in range(128)
[03:28] I bet that is able to be provoked directly [03:28] Probably, yes. [03:28] Now I actually read it. [03:28] which is why I said good [03:28] this is just more tech debt in our stack [03:28] * StevenK grumbles at LostObjectError some more. [03:29] StevenK: What's the test? [03:29] wgrant: http://pastebin.ubuntu.com/752154/ [03:30] view.errors is throwing LostObjectError. [03:30] wgrant: you, hitting enter on that just breaks directly in the form widget [03:30] wgrant: so any logged in browser getting that from apport will barf in-place [03:31] lifeless: It works on prod [03:32] how verra interesting [03:32] Rather [03:32] * wgrant checks what the post-login URL is. [03:32] given I only touch openidloginview [03:32] https://bugs.launchpad.dev/firefox/+filebug?field.title=package%20uml-utilities%2020070815-1.1ubuntu2%20failed%20to%20install/upgrade%3A%20el%20subproc%E9s%20post-installation%20script%20retorn%E0%20el%20codi%20d%27eixida%20d%27error%201 [03:32] wgrant: I get the same issue in a unit test [03:32] https://bugs.launchpad.net/ubuntu/+filebug?field.title=package%20uml-utilities%2020070815-1.1ubuntu2%20failed%20to%20install/upgrade:%20el%20subproc%C3%A9s%20post-installation%20script%20retorn%C3%A0%20el%20codi%20d'eixida%20d'error%201 [03:32] https://bugs.launchpad.net/launchpad/+filebug?field.title=package%20uml-utilities%2020070815-1.1ubuntu2%20failed%20to%20install/upgrade%3A%20el%20subproc%E9s%20post-installation%20script%20retorn%E0%20el%20codi%20d%27eixida%20d%27error%201 [03:32] is a prod url that barfs [03:32] Yep [03:32] Wait [03:33] the reason the +login transition url works is because of the entity escaping [03:33] Your prod URL is a post-login one that breaks, or one that works? [03:33] wgrant: breaks [03:33] wgrant: [03:33] attr_list.append(u'%s=%s' % (key, quoteattr(unicode(value)))) [03:33] UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 79: ordinal not in range(128)
[03:33] on prod [03:33] So, looks like you need to fix that first. [03:33] Rather than rebreaking apport again. [03:34] However, looks like your login fix is good. [03:34] wgrant: you misunderstand [03:34] It's just +filebug that's crap now. [03:34] wgrant: apport starts with a normal url right ? [03:34] wgrant: *if* the browser isn't logged in, they get a login bounce around [03:34] wgrant: right now, if the browser *is* logged in, it will simply fail straight up [03:34] Huh, indeed it does. [03:34] Unless the redirect *to* +login is breaking stuff. [03:35] wgrant: If the browser isn't logged in, it will get a login bounce around, which will 'fix' it while making the search for dupes unable to find anything. [03:35] wgrant: so no, I don't think the +filebug issue needs fixing before landing the login fix. [03:35] lifeless: Do we know that the original URL doesn't work? [03:36] wgrant: we don't have the original url anywhere that I can see [03:36] The query string may already have been mangled, because we're looking at URLs that already contain +login. [03:36] Your explanation seems reasonable, however. [03:37] possibly in a referer if we have any of the oopses around [03:38] Did we get a new spinner last week? [03:38] It looks different now. [03:38] none of the oopses have a referer [03:38] twitch [03:38] That's upsetting. [03:38] it is [03:38] including ones on shipit [03:41] wgrant: Any ideas? :-( [03:41] StevenK: Sorry, distractions abound. [03:41] * wgrant looks. [03:41] Clearly. [03:42] StevenK: What's the traceback on the LOE? [03:42] However, it'spossible that create_initialized_view is aborting the transaction on error. [03:42] If you commit before it, it might be happier. [03:42] Because the person and project will still exist after the view transaction is aborted. [03:42] wgrant: http://pastebin.ubuntu.com/752157/ [03:43] Yeah, I suspect the transaction is being aborted. Try committing before create_initialized_view [03:44] I get it. The rest of that doctest uses sampledata. Which does not need to be nailed into the DB. [03:46] Bloody sampledata. [03:48] StevenK: wanna review? https://code.launchpad.net/~jtv/launchpad/bug-849683/+merge/83546 [03:48] Updates sample data, funnily enough. [03:51] I'd rather sort out this validate() method, sorry. [03:51] OK, I'll pounce on someone else. [03:51] But I thought you'd at least want to know! === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 [03:53] Oh, fan-bloody-tastic, we're at 300? [03:53] Hah [03:53] 3E2? :) [03:53] In its own small way, dropping the 3rd significant digit is progress. [03:54] Critical bugtasks: 0x12c [03:55] StevenK: That doesn't quite so effectively prevent me from updating it a couple of times a day. [03:55] jtv: reviewed [03:55] But it *looks* smaller [03:55] Thanks! [03:56] jtv: tl;dr - I'd keep the job for now. [03:56] jtv: as insurance [03:56] Against what, though? [03:56] jtv: bugs that we don't know about causing NULL values in the column [03:56] We're not going to start using these until we have the constraint in place, are we? [03:57] jtv: the constraint adding will need the migrator to run on any such faulty rows, should they appear. [03:57] From this point on, I'd rather have breakage when adding the constraint than bugs silently hidden by the jobs. [03:57] jtv: breakage adding the constraint extends downtime [03:58] Well [03:58] jtv: I'm very much against extending site wide downtime vs having bugs turn up later [03:58] Not if we disable the jobs first; then we can detect them with a simple pair of queries. [03:58] There are very probably still creators that need to be updated. [03:58] As jtv says, we can detect them easily this way. [03:58] although it might be better to just disable the migrator for a few days first. [03:58] I'm even more against hiding bugs until they hit production. [03:58] you'll need to reinstate the migrator to correct the rows any which way [03:59] how about making sure the test suite passes with such a constraint added, as a first step ? [03:59] That's what we have bzr for, isn't it? [03:59] jtv: bzr doesn't really cut down on the 8 hour latency to land something [03:59] Yes, running the test suite with the constraint is a good one. [04:01] Don't remove it, move it to --experimental [04:01] Then it doesn't get run by default [04:01] See if the numbers are creeping up [04:03] wgrant: for your entertainment - bug 897053 [04:03] Hm, must be only a few days left. [04:03] Until 900000 [04:03] lifeless: Thanks. [04:04] over 900000 [04:04] Unconventional, but indeed. [04:05] StevenK: see if what numbers are creeping up exactly? It doesn't look like the populators have found any new rows to populate recently. [04:06] jtv: So. Disable the populators by moving them to experimental. Get that rolled out to prod. Check if sourcepackagename IS NULL is non-zero after 24 hours, same for binarypackagename IS NULL. [04:07] StevenK: but what would be the difference with checking the populator logs now? [04:07] jtv: That will tell you if there are other codepaths are not creating SPPHs or BPPHs without setting the name. [04:07] Which will blow up if you add the NOT NULL constraint. [04:07] I'd suggest moving to experimental; so that *if, when the constraints time comes*, we have a readily available plan B, rather than rollbacks and 8+ hours of delay [04:08] StevenK: but what would be the difference with checking the populator logs now? [04:08] costs nothing, provides support. [04:08] jtv: there isn't any difference vs checking the logs now, you are correct on that [04:08] Checking the logs now costs less. [04:08] Which is what I've been doing. [04:08] jtv: Less risk [04:08] jtv: the main thing is the cost of recovery, if its needed. [04:08] Versus 8+ hours of delay due to rollbacks [04:08] More steps, more latency, more complication, no extra coverage — that's *more* risk. [04:09] no additional latency, one more step. [04:10] wow, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-99869e94b028f4641c1feeb4806ed88e has a horrible query count [04:11] How is an additional step not additional latency? And we know for a fact that no unpopulated rows have been found since Wednesday. [04:12] because its not serialised [04:12] the critical path to using the columns is 'add constraint [if possible]; profit' [04:12] thats the same critical path if you keep the job or not [04:13] If you omit “change the branch, come back and clean up the jobs again later.” [04:14] those things don't impact the ability to use the columns [04:14] why should they be included in the critical path? [04:15] Okay, so they're not in the critical path. Then why should I do them? [04:16] Note that apparently we can't proceed with the critical path if I don't. [04:16] because once we're able to use the column they become tech debt [04:16] I don't understand why you can't proceed. Can you expand on that? [04:17] You seem to insist that I move the populators back in before landing this branch. [04:17] Here's another consideration though: [04:17] We haven't seen any broken rows appear for 5 days. [04:18] If we still have code that creates broken rows, how big are the chances that it will create enough of them to necessitate a loop tuner between the time we retire the populators and the time we add the constraints? [04:19] AFAICS we're just optimizing for failure rather than protecting from it. [04:21] moving the populator back in would be very simple here and avoid latency later when it might be needed. I proposing to optimise for less team-wide and user-wide impact should failure occur [04:21] the probability thing is a good question [04:24] Anyway, I'm shelving this for now; I do have more urgent things to work on. Maybe I'll check the logs again in a few days or something. [04:30] There were 1 imports of names not appearing in the __all__. [04:30] You should not import _details_to_str from testtools.testresult.real: [04:30] canonical.launchpad.scripts.runlaunchpad [04:33] poolie: Is it meant to be .tgz rather than something sensible? [04:33] We aren't using DOS or 16-bit Windows any more :) [04:33] isn't it tgz? [04:33] It's a gzipped tarball, yes. [04:34] oh '.tar.gz' [04:34] But the conventional extension for a gzipped tarball is .tar.gz. [04:34] http://achewood.com/index.php?date=11222006 [04:34] Heh [04:34] it was slightly easier to write this way [04:34] i can change it [04:35] I haven't seen anybody use .tgz in yeeeears. [04:35] So if it's easy... [04:36] Anyone keen to review another oversized branch? :) [04:36] Though this one's only 2000 lines, not 3300. [04:36] i'm going to revisit it to add more links [04:36] +124/-441 [04:36] as long as most of them are minuses :) [04:36] wgrant: What are you ripping out? [04:36] StevenK: CodeLayer and TranslationsLayer [04:36] Won't land this one until I've confirmed with mrevell, though. [04:37] And renaming TranslationsLayer:DistroSeries:+admin ? [04:37] Not yet. [04:37] Does that make it unreachable if it lands? [04:37] shouldn't the translations admin become an expandable onthe one +admin/ [04:37] if you're thinking streamlined UI that is [04:40] I'm thinking about destroying subdomains. [04:41] Not thinking streamlined UI. [04:41] StevenK: No. [04:41] StevenK: It's still on translations.launchpad.dev, and this doesn't change any links. [04:41] It just makes the views accessible in more places. [04:41] Right. Link me? [04:41] The layers still exist, and are bound to the relevant publishers. But there's only one view left bound to them. [04:41] https://code.launchpad.net/~wgrant/launchpad/delayer-views/+merge/83547 [04:43] lib/canonical/launchpad/pagetests/basics/notfound-traversals.txt is quite disgusting [04:43] Actually, I lie. There are three ancient pre-1.0 tour redirects left bound to each layer, but they can die later. [04:43] Because nothing links to them. [04:43] yes. [04:43] It doesn't take 4 minutes to run any more, though. [04:43] Only like 90 seconds. [04:43] Not sure why. [04:46] wgrant: Why did you remove TranslateRedirectView and not TranslationsRedirectView, the latter of which is actually implicated in the ZCML? [04:47] StevenK: Both were used in ZCML, to redirect to the corresponding pages on translations.launchpad.net. But TranslateRedirectView has one remaining use: SP:+translate -> SP:+translations. I believe that's in place due to old liblaunchpad-integrations, from before Gutsy, but I need to confirm that nobody's still using it. [04:48] wgrant: Why not remove both, then? [04:48] Because SP:+translate may still be pointed to by something. [04:48] It redirects to +translations, not just to a different vhost. [04:49] That would break a URL that works now, which is not something I want the branch to do. [04:49] wgrant: You say TranslateRedirectView might still be used, but you're still removing it? [04:49] StevenK: TranslationsRedirectView is removed [04:49] TranslateRedirectView remains. [04:50] The diff says otherwise. [04:50] 2008 -class TranslateRedirectView(PageRedirectView): [04:50] Ah, right, I misremembered. [04:50] Was thinking that it was named after where it redirects *from*, which of course makes no sense. [04:51] We still need to redirect to +translations, to TranslationsRedirectView remains. [04:51] s/to Trans/so Trans/ [04:51] The tests pass like this, anyway :) [04:52] And .dev behaves like you expect it to, re SP:+translate ? [04:53] Yes. [04:53] TranslationsRedirectView will later be changed to redirect to mainsite instead of translations, but not yet. [04:54] And then everything except mainsite will hopefully mysteriously evaporate next week. [04:54] Weren't we still using that one for the licensing-agreement redirect? [04:54] wgrant: Approved. [04:55] jtv: The only redirects I touched were unconditional ones to +translate or +translations. [04:55] +licensing is now available on mainsite too instead of just translations, but that's all I've changed relating to that. [04:55] Very possible that I'm wrong; just asking. [04:55] Sure, always best to be safe in stuff like this :) [04:56] The redirect was covered in a pagetest, at least at some indefinite point in the past. [04:56] Hmm. [04:56] Which redirect? [04:56] * StevenK grumbles. [04:56] I'm just having a quick check. [04:56] StevenK: SourcePackage:+translations is still hit... 10000 times last month. I wonder where from. [04:57] +translations or +translate? [04:57] Bah, +translate [04:57] This validate method gets no owner in two cases. :-( [04:57] If it's hit that often, I should have a referrer in some logs. [04:57] No owner when the specified team is open, or if the field is empty. [04:58] Maybe I should just reach into view.errors and pull out the ConstraintNotValid [04:58] That will let me tell the difference. [05:00] Hmmm [05:00] Firefox 4 [05:00] Old. [05:00] Although it's natty. [05:00] huuuuh [05:00] /ubuntu/gutsy/+sources/kdebase/+translate [05:00] Since when does +sources exist? [05:01] Isn't it +source? [05:01] I thought so. [05:02] Is anyone still running natty? [05:03] Ah, I have a VM. [05:04] Natty's Firefox still uses SP:+translate :( [05:04] liblaunchpad-integration was fixed years ago. [05:04] So we can't drop the redirect yet. [05:05] And Firefox to this day uses https://launchpad.net/distros/ubuntu/oneiric/+sources/firefox/+gethelp [05:05] Should probably fix that before Precise locks us into supporting that triply deprecated URL for another 5 years. [05:05] * wgrant files. [05:08] I guess we can SRU it away in a few weeks, too. [05:10] jtv: What's the best view to link to for source package translations? SP:+translations? [05:10] +translate is clearly deprecated, but I don't know if there's something better. [05:11] wgrant: At least it doesn't use edge :-P [05:11] wgrant: was +translations that complete rewrite of the view that we didn't quite complete about 2 years ago? [05:11] jtv: +translate redirects to +translations now [05:14] wgrant: I can only speculate at this point. This may have been the new view that we kept unlinked in parallel to the old one, under a separate name, until it was completed. That _could_ be the full explanation for the redirect and the new name. [05:15] To verify that, you could dig up the history to see if the views ever existed side by side. [05:15] With very similar class names. [05:15] * jtv digs up timing information [05:19] wgrant: they'd probably have existed side by side in early 2010. [05:19] jtv: Aha, thanks. [05:19] +translations looks to be the way to go. [05:20] Speaking purely aesthetically, I'm not entirely happy with that. It's pretty much all “translations,” isn't it? [05:20] Hmm? [05:20] The subdomains are probably not long for this world. [05:21]