[00:01] <wgrant> huwshimi: lp:~wgrant/launchpad/the-one-domain isn't perfect yet, but it's 90% done.
[00:02] <huwshimi> wgrant: Dude, that's fantastic!
[00:03] <wgrant> A few links still lead to the wrong place, but it pretty much works.
[00:04] <huwshimi> wgrant: That's really awesome. Did you manage to solve breadcrumb stuff?
[00:05] <wgrant> huwshimi: Yeah, that all works.
[00:05] <huwshimi> wgrant: :D
[00:05] <wgrant> 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] <huwshimi> awesome
[00:13] <huwshimi> wgrant: It's so nice browsing through the facets with the urls like that
[00:14] <wgrant> I just used the existing view names. some like +specs probably want to be renamed.
[00:15] <wgrant> And we probably want to get rid of +bugs-index
[00:15] <wgrant> (that's the crippled version of +bugs which only shows the top 10 bugs by heat)
[00:15] <StevenK> Isn't that used by a projects page?
[00:15] <huwshimi> wgrant: Yeah, but a great start
[00:16] <wgrant> StevenK: Yes, but it is pointless and there was discussion last week that it might be removed.
[00:23] <poolie> lifeless, incidentally it looks like at least in dev, memcached is used for comment rendering still
[00:24] <lifeless> yes, if the flag is off
[00:57] <StevenK> Rargh, why is creating a view raising LostObjectError
[00:57] <wgrant> StevenK: O_o have you been aborting transactions or something?
[00:57] <StevenK> Certainly not.
[01:06]  * lifeless stabitty stabitty openidloginview
[01:11] <lifeless> wgrant: can I nab you for a minute
[01:12] <wgrant> lifeless: Sure
[01:12] <lifeless> skype?
[01:12] <wgrant> sec
[01:12] <lifeless> want to get this openid fail fixed
[01:16] <lifeless> wgrant: e.g. https://launchpad.dev/%7Emario-sitz/+archive/ppa/+login?field%85ries_filter=lucid
[01:23] <lifeless> wgrant: there?
[01:31] <lifeless> wgrant: hahahahahahahahahahahahahahahaa
[01:32] <wgrant> Oh god.
[01:32] <wgrant> What now?
[01:32] <lifeless> eggs/zope.publisher-3.12.0-py2.6.egg/zope/publisher/http.py line 522
[01:33] <wgrant> lifeless: That doesn't sound particularly relevant here.
[01:33] <wgrant> It's the query string we really care about.
[01:33] <lifeless> wgrant: the old code before the 6* bug was fixed called getURL
[01:33] <lifeless> wgrant: anyhow
[01:46] <lifeless> wgrant: yes, its broken
[01:46] <lifeless> 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] <lifeless> wgrant: thats using a not-unicode-at-all value in the current code
[01:46] <wgrant> Hah
[01:46] <lifeless> note the x2026
[01:47] <lifeless> entity escaping
[01:47] <wgrant> Yeah.
[01:47] <mwhudson> this brings back horrible memories
[01:49] <lifeless> mwhudson: indeed
[01:49] <mwhudson> mod_rewrite isn't involved is it?
[01:49] <lifeless> mwhudson: now
[01:49] <wgrant> Not this time.
[01:50] <lifeless> mwhudson: no, just some dubious code in the openid login view
[01:50] <mwhudson> oh good
[01:50] <lifeless> mwhudson: see the form_args property in login.py
[01:50] <lifeless> mwhudson: and see if you can spot the two separate defects
[01:50] <mwhudson> mind you doing, string ops on urls unless you are exceedingly careful about normalization is ... a bad idea, i guess
[01:52] <lifeless> indeed
[01:52] <lifeless> I keep meaning to write a stringlike url class
[01:52] <lifeless> that will refuse unsafe things and not be horribly slow
[01:52] <lifeless> then I realise I have useful things to do
[01:52] <mwhudson> lifeless: well, i don't know what UnicodeDammit does
[01:53] <mwhudson> and well yeah, no escaping?  i don't know enough about request.form.items() to be specific
[01:53] <wgrant> It's good for screen-scraping.
[01:53] <wgrant> It's not good for this.
[01:53] <mwhudson> e.g. if value_list_item was 'a&b=c' this could obviously be hilarious
[01:54] <lifeless> mwhudson: as is a&b=c\x85
[01:54] <lifeless> mwhudson: thats bug one - unicodedammit does entity escaping
[02:27] <lifeless> ok, time for zope esoterica
[02:27] <lifeless> whats teh difference between request.items() and request.form.items() ?
[02:34] <wgrant> lifeless: request.items() includes cookies, environ and form.
[02:41] <wgrant> Aha
[02:41] <wgrant> Just caught an ec2 run with the poppy error before it finished.
[02:41]  * wgrant investigates.
[02:41] <wgrant> There's already a poppy-sftp running. Something's not cleaning up.
[02:43] <wgrant> It's lp.poppy.tests.test_poppy.TestPoppy.test_bad_gpg_on_changesfile(ftp)
[02:44] <lifeless> well, thats something we have prod issues with
[02:44] <lifeless> \o/
[02:52] <wgrant> Baaaaaaaaaaah
[02:52] <wgrant> Does ec2 shut down if it sees the testrunner hung?
[02:52] <wgrant> I thought it just shut down after 8 hours or something.
[03:02] <jtv> StevenK: the BPPH.bpn populator is done.
[03:03] <jtv> It's not very easily noticed in the logs, since it basically blocks, blocks, blocks, and then gets killed.
[03:07] <lifeless> wgrant: up for a review of what we discussed earlier ?
[03:11] <wgrant> lifeless: Sure
[03:11] <lifeless> 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] <wgrant> Got enough criticals linked to that?
[03:13] <wgrant> Oh, it's the old branch, I see.
[03:13] <lifeless> yeah
[03:13] <lifeless> it crept
[03:13] <wgrant> Woot
[03:13] <lifeless> I didn't realise I was working on the wrong thing initially
[03:13]  * wgrant finds another OOPS
[03:13] <wgrant> There must be one here somewhere...
[03:14] <wgrant> Tempting to make bug #890976 critical, as it hinders determination of timeout causes.
[03:14] <wgrant> And it would make 300 tasks.
[03:15] <wgrant> Which is an important milestone.
[03:15] <lifeless> bug 890976
[03:15] <wgrant> enomup
[03:15] <wgrant> Bug #890976: hard to determine causes of late evaluation
[03:15] <lifeless> its fixed ;)
[03:15] <wgrant> Bah.
[03:15] <wgrant> That's not very useful, then.
[03:16] <lifeless> dunno why it wasn't marked f-r when deployed
[03:17] <wgrant> lifeless: Anyway, I'm looking at your branch and trying to break it.
[03:18] <lifeless> thanks
[03:19] <wgrant> O
[03:19] <wgrant> h
[03:19] <wgrant> A new critical
[03:19] <wgrant> Where'd that come from...
[03:19] <wgrant> victory
[03:20] <wgrant> Ah, it was you.
[03:21] <lifeless> timeout errors apprpving your MP
[03:21] <wgrant> Awesome.
[03:21] <wgrant> BranchRevision?
[03:21] <lifeless> no OOPS reported
[03:21] <wgrant> Or Branch FKs/
[03:21] <wgrant> Pardon?
[03:21] <wgrant> 502s, then?
[03:21] <lifeless> just a just popup saying 'timeout error'
[03:21] <wgrant> oh
[03:21] <wgrant> heh
[03:22] <wgrant> OOPS ID should be in the top right AJAX log thingy.
[03:22] <lifeless> no
[03:22] <wgrant> Lies.
[03:22] <lifeless> ID: 0, status: 503 (Service Unavailable)
[03:22] <wgrant> Hmmmm.
[03:22] <wgrant> Oddity.
[03:22] <lifeless> ENOTLYING
[03:22] <wgrant> Liar.
[03:22] <wgrant> I wonder if its OOPS matching breaks with the new scheme.
[03:22] <wgrant> But surely not.
[03:22] <wgrant> IIRC it just checks X-Lazr-OopsId
[03:22] <lifeless> case sensitive ?
[03:23] <wgrant> No idea.
[03:23] <wgrant> Anyway.
[03:24] <wgrant> 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] <wgrant> :)
[03:25] <wgrant> 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] <lifeless> good :)
[03:25] <wgrant> s@/bugs/@/firefox/@ to make it mostly work.
[03:25] <wgrant> Why?
[03:25] <lifeless> closer to the right place
[03:26] <wgrant> Heh
[03:26] <wgrant> Looks relatively sane otherwise.
[03:27] <lifeless> wgrant: doesn't oops for me
[03:27] <lifeless> wgrant: it just does a 404 error
[03:27] <wgrant> lifeless: /bugs/+filebug doesn't exist any more.
[03:27] <lifeless> wgrant: (a 404 same-domain oops that is)
[03:27] <wgrant> Use eg. /firefox/+filebug instead
[03:27] <wgrant>     Module zope.app.form.browser.widget, line 522, in renderTag
[03:27] <wgrant>     attr_list.append(u'%s=%s' % (key, quoteattr(unicode(value))))
[03:27] <wgrant> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 79: ordinal not in range(128)<br />
[03:28] <lifeless> I bet that is able to be provoked directly
[03:28] <wgrant> Probably, yes.
[03:28] <wgrant> Now I actually read it.
[03:28] <lifeless> which is why I said good
[03:28] <lifeless> this is just more tech debt in our stack
[03:28]  * StevenK grumbles at LostObjectError some more.
[03:29] <wgrant> StevenK: What's the test?
[03:29] <StevenK> wgrant: http://pastebin.ubuntu.com/752154/
[03:30] <StevenK> view.errors is throwing LostObjectError.
[03:30] <lifeless> wgrant: you, hitting enter on that just breaks directly in the form widget
[03:30] <lifeless> wgrant: so any logged in browser getting that from apport will barf in-place
[03:31] <wgrant> lifeless: It works on prod
[03:32] <lifeless> how verra interesting
[03:32] <wgrant> Rather
[03:32]  * wgrant checks what the post-login URL is.
[03:32] <lifeless> given I only touch openidloginview
[03:32] <lifeless> 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] <StevenK> wgrant: I get the same issue in a unit test
[03:32] <wgrant> 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] <lifeless> 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] <lifeless> is a prod url that barfs
[03:32] <wgrant> Yep
[03:32] <wgrant> Wait
[03:33] <lifeless> the reason the +login transition url works is because of the entity escaping
[03:33] <wgrant> Your prod URL is a post-login one that breaks, or one that works?
[03:33] <lifeless> wgrant: breaks
[03:33] <lifeless> wgrant:
[03:33] <lifeless>     attr_list.append(u'%s=%s' % (key, quoteattr(unicode(value))))
[03:33] <lifeless> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 79: ordinal not in range(128)<br />
[03:33] <lifeless> on prod
[03:33] <wgrant> So, looks like you need to fix that first.
[03:33] <wgrant> Rather than rebreaking apport again.
[03:34] <wgrant> However, looks like your login fix is good.
[03:34] <lifeless> wgrant: you misunderstand
[03:34] <wgrant> It's just +filebug that's crap now.
[03:34] <lifeless> wgrant: apport starts with a normal url right ?
[03:34] <lifeless> wgrant: *if* the browser isn't logged in, they get a login bounce around
[03:34] <lifeless> wgrant: right now, if the browser *is* logged in, it will simply fail straight up
[03:34] <wgrant> Huh, indeed it does.
[03:34] <wgrant> Unless the redirect *to* +login is breaking stuff.
[03:35] <lifeless> 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] <lifeless> wgrant: so no, I don't think the +filebug issue needs fixing before landing the login fix.
[03:35] <wgrant> lifeless: Do we know that the original URL doesn't work?
[03:36] <lifeless> wgrant: we don't have the original url anywhere that I can see
[03:36] <wgrant> The query string may already have been mangled, because we're looking at URLs that already contain +login.
[03:36] <wgrant> Your explanation seems reasonable, however.
[03:37] <lifeless> possibly in a referer if we have any of the oopses around
[03:38] <wgrant> Did we get a new spinner last week?
[03:38] <wgrant> It looks different now.
[03:38] <lifeless> none of the oopses have a referer
[03:38] <lifeless> twitch
[03:38] <wgrant> That's upsetting.
[03:38] <lifeless> it is
[03:38] <lifeless> including ones on shipit
[03:41] <StevenK> wgrant: Any ideas? :-(
[03:41] <wgrant> StevenK: Sorry, distractions abound.
[03:41]  * wgrant looks.
[03:41] <StevenK> Clearly.
[03:42] <wgrant> StevenK: What's the traceback on the LOE?
[03:42] <wgrant> However, it'spossible that create_initialized_view is aborting the transaction on error.
[03:42] <wgrant> If you commit before it, it might be happier.
[03:42] <wgrant> Because the person and project will still exist after the view transaction is aborted.
[03:42] <StevenK> wgrant: http://pastebin.ubuntu.com/752157/
[03:43] <wgrant> Yeah, I suspect the transaction is being aborted. Try committing before create_initialized_view
[03:44] <StevenK> I get it. The rest of that doctest uses sampledata. Which does not need to be nailed into the DB.
[03:46] <StevenK> Bloody sampledata.
[03:48] <jtv> StevenK: wanna review?  https://code.launchpad.net/~jtv/launchpad/bug-849683/+merge/83546
[03:48] <jtv> Updates sample data, funnily enough.
[03:51] <StevenK> I'd rather sort out this validate() method, sorry.
[03:51] <jtv> OK, I'll pounce on someone else.
[03:51] <jtv> But I thought you'd at least want to know!
[03:53] <StevenK> Oh, fan-bloody-tastic, we're at 300?
[03:53] <wgrant> Hah
[03:53] <wgrant> 3E2? :)
[03:53] <jtv> In its own small way, dropping the 3rd significant digit is progress.
[03:54] <StevenK> Critical bugtasks: 0x12c
[03:55] <wgrant> StevenK: That doesn't quite so effectively prevent me from updating it a couple of times a day.
[03:55] <lifeless> jtv: reviewed
[03:55] <StevenK> But it *looks* smaller
[03:55] <jtv> Thanks!
[03:56] <lifeless> jtv: tl;dr - I'd keep the job for now.
[03:56] <lifeless> jtv: as insurance
[03:56] <jtv> Against what, though?
[03:56] <lifeless> jtv: bugs that we don't know about causing NULL values in the column
[03:56] <jtv> We're not going to start using these until we have the constraint in place, are we?
[03:57] <lifeless> jtv: the constraint adding will need the migrator to run on any such faulty rows, should they appear.
[03:57] <jtv> From this point on, I'd rather have breakage when adding the constraint than bugs silently hidden by the jobs.
[03:57] <lifeless> jtv: breakage adding the constraint extends downtime
[03:58] <wgrant> Well
[03:58] <lifeless> jtv: I'm very much against extending site wide downtime vs having bugs turn up later
[03:58] <jtv> Not if we disable the jobs first; then we can detect them with a simple pair of queries.
[03:58] <wgrant> There are very probably still creators that need to be updated.
[03:58] <wgrant> As jtv says, we can detect them easily this way.
[03:58] <wgrant> although it might be better to just disable the migrator for a few days first.
[03:58] <jtv> I'm even more against hiding bugs until they hit production.
[03:58] <lifeless> you'll need to reinstate the migrator to correct the rows any which way
[03:59] <lifeless> how about making sure the test suite passes with such a constraint added, as a first step ?
[03:59] <jtv> That's what we have bzr for, isn't it?
[03:59] <lifeless> jtv: bzr doesn't really cut down on the 8 hour latency to land something
[03:59] <jtv> Yes, running the test suite with the constraint is a good one.
[04:01] <StevenK> Don't remove it, move it to --experimental
[04:01] <StevenK> Then it doesn't get run by default
[04:01] <StevenK> See if the numbers are creeping up
[04:03] <lifeless> wgrant: for your entertainment - bug 897053
[04:03] <wgrant> Hm, must be only a few days left.
[04:03] <wgrant> Until 900000
[04:03] <wgrant> lifeless: Thanks.
[04:04] <lifeless> over 900000
[04:04] <wgrant> Unconventional, but indeed.
[04:05] <jtv> 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] <StevenK> 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] <jtv> StevenK: but what would be the difference with checking the populator logs now?
[04:07] <StevenK> jtv: That will tell you if there are other codepaths are not creating SPPHs or BPPHs without setting the name.
[04:07] <StevenK> Which will blow up if you add the NOT NULL constraint.
[04:07] <lifeless> 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] <jtv> StevenK: but what would be the difference with checking the populator logs now?
[04:08] <lifeless> costs nothing, provides support.
[04:08] <lifeless> jtv: there isn't any difference vs checking the logs now, you are correct on that
[04:08] <jtv> Checking the logs now costs less.
[04:08] <jtv> Which is what I've been doing.
[04:08] <StevenK> jtv: Less risk
[04:08] <lifeless> jtv: the main thing is the cost of recovery, if its needed.
[04:08] <StevenK> Versus 8+ hours of delay due to rollbacks
[04:08] <jtv> More steps, more latency, more complication, no extra coverage — that's *more* risk.
[04:09] <lifeless> no additional latency, one more step.
[04:10] <lifeless> wow,  https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-99869e94b028f4641c1feeb4806ed88e has a horrible query count
[04:11] <jtv> 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] <lifeless> because its not serialised
[04:12] <lifeless> the critical path to using the columns is 'add constraint [if possible]; profit'
[04:12] <lifeless> thats the same critical path if you keep the job or not
[04:13] <jtv> If you omit “change the branch, come back and clean up the jobs again later.”
[04:14] <lifeless> those things don't impact the ability to use the columns
[04:14] <lifeless> why should they be included in the critical path?
[04:15] <jtv> Okay, so they're not in the critical path.  Then why should I do them?
[04:16] <jtv> Note that apparently we can't proceed with the critical path if I don't.
[04:16] <lifeless> because once we're able to use the column they become tech debt
[04:16] <lifeless> I don't understand why you can't proceed. Can you expand on that?
[04:17] <jtv> You seem to insist that I move the populators back in before landing this branch.
[04:17] <jtv> Here's another consideration though:
[04:17] <jtv> We haven't seen any broken rows appear for 5 days.
[04:18] <jtv> 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] <jtv> AFAICS we're just optimizing for failure rather than protecting from it.
[04:21] <lifeless> 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] <lifeless> the probability thing is a good question
[04:24] <jtv> 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] <StevenK> There were 1 imports of names not appearing in the __all__.
[04:30] <StevenK> You should not import _details_to_str from testtools.testresult.real:
[04:30] <StevenK>     canonical.launchpad.scripts.runlaunchpad
[04:33] <wgrant> poolie: Is it meant to be .tgz rather than something sensible?
[04:33] <wgrant> We aren't using DOS or 16-bit Windows any more :)
[04:33] <poolie> isn't it tgz?
[04:33] <wgrant> It's a gzipped tarball, yes.
[04:34] <poolie> oh '.tar.gz'
[04:34] <wgrant> But the conventional extension for a gzipped tarball is .tar.gz.
[04:34] <poolie> http://achewood.com/index.php?date=11222006
[04:34] <wgrant> Heh
[04:34] <poolie> it was slightly easier to write this way
[04:34] <poolie> i can change it
[04:35] <wgrant> I haven't seen anybody use .tgz in yeeeears.
[04:35] <wgrant> So if it's easy...
[04:36] <wgrant> Anyone keen to review another oversized branch? :)
[04:36] <wgrant> Though this one's only 2000 lines, not 3300.
[04:36] <poolie> i'm going to revisit it to add more links
[04:36] <wgrant> +124/-441
[04:36] <poolie> as long as most of them are minuses :)
[04:36] <StevenK> wgrant: What are you ripping out?
[04:36] <wgrant> StevenK: CodeLayer and TranslationsLayer
[04:36] <wgrant> Won't land this one until I've confirmed with mrevell, though.
[04:37] <StevenK> And renaming TranslationsLayer:DistroSeries:+admin ?
[04:37] <wgrant> Not yet.
[04:37] <StevenK> Does that make it unreachable if it lands?
[04:37] <lifeless> shouldn't the translations admin become an expandable onthe one +admin/
[04:37] <lifeless> if you're thinking streamlined UI that is
[04:40] <wgrant> I'm thinking about destroying subdomains.
[04:41] <wgrant> Not thinking streamlined UI.
[04:41] <wgrant> StevenK: No.
[04:41] <wgrant> StevenK: It's still on translations.launchpad.dev, and this doesn't change any links.
[04:41] <wgrant> It just makes the views accessible in more places.
[04:41] <StevenK> Right. Link me?
[04:41] <wgrant> The layers still exist, and are bound to the relevant publishers. But there's only one view left bound to them.
[04:41] <wgrant> https://code.launchpad.net/~wgrant/launchpad/delayer-views/+merge/83547
[04:43] <StevenK> lib/canonical/launchpad/pagetests/basics/notfound-traversals.txt is quite disgusting
[04:43] <wgrant> Actually, I lie. There are three ancient pre-1.0 tour redirects left bound to each layer, but they can die later.
[04:43] <wgrant> Because nothing links to them.
[04:43] <wgrant> yes.
[04:43] <wgrant> It doesn't take 4 minutes to run any more, though.
[04:43] <wgrant> Only like 90 seconds.
[04:43] <wgrant> Not sure why.
[04:46] <StevenK> wgrant: Why did you remove TranslateRedirectView and not TranslationsRedirectView, the latter of which is actually implicated in the ZCML?
[04:47] <wgrant> 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] <StevenK> wgrant: Why not remove both, then?
[04:48] <wgrant> Because SP:+translate may still be pointed to by something.
[04:48] <wgrant> It redirects to +translations, not just to a different vhost.
[04:49] <wgrant> That would break a URL that works now, which is not something I want the branch to do.
[04:49] <StevenK> wgrant: You say TranslateRedirectView might still be used, but you're still removing it?
[04:49] <wgrant> StevenK: TranslationsRedirectView is removed
[04:49] <wgrant> TranslateRedirectView remains.
[04:50] <StevenK> The diff says otherwise.
[04:50] <StevenK> 2008 -class TranslateRedirectView(PageRedirectView):
[04:50] <wgrant> Ah, right, I misremembered.
[04:50] <wgrant> Was thinking that it was named after where it redirects *from*, which of course makes no sense.
[04:51] <wgrant> We still need to redirect to +translations, to TranslationsRedirectView remains.
[04:51] <wgrant> s/to Trans/so Trans/
[04:51] <wgrant> The tests pass like this, anyway :)
[04:52] <StevenK> And .dev behaves like you expect it to, re SP:+translate ?
[04:53] <wgrant> Yes.
[04:53] <wgrant> TranslationsRedirectView will later be changed to redirect to mainsite instead of translations, but not yet.
[04:54] <wgrant> And then everything except mainsite will hopefully mysteriously evaporate next week.
[04:54] <jtv> Weren't we still using that one for the licensing-agreement redirect?
[04:54] <StevenK> wgrant: Approved.
[04:55] <wgrant> jtv: The only redirects I touched were unconditional ones to +translate or +translations.
[04:55] <wgrant> +licensing is now available on mainsite too instead of just translations, but that's all I've changed relating to that.
[04:55] <jtv> Very possible that I'm wrong; just asking.
[04:55] <wgrant> Sure, always best to be safe in stuff like this :)
[04:56] <jtv> The redirect was covered in a pagetest, at least at some indefinite point in the past.
[04:56] <wgrant> Hmm.
[04:56] <wgrant> Which redirect?
[04:56]  * StevenK grumbles.
[04:56] <jtv> I'm just having a quick check.
[04:56] <wgrant> StevenK: SourcePackage:+translations is still hit... 10000 times last month. I wonder where from.
[04:57] <StevenK> +translations or +translate?
[04:57] <wgrant> Bah, +translate
[04:57] <StevenK> This validate method gets no owner in two cases. :-(
[04:57] <wgrant> If it's hit that often, I should have a referrer in some logs.
[04:57] <StevenK> No owner when the specified team is open, or if the field is empty.
[04:58] <StevenK> Maybe I should just reach into view.errors and pull out the ConstraintNotValid
[04:58] <StevenK> That will let me tell the difference.
[05:00] <wgrant> Hmmm
[05:00] <wgrant> Firefox 4
[05:00] <wgrant> Old.
[05:00] <wgrant> Although it's natty.
[05:00] <wgrant> huuuuh
[05:00] <wgrant> /ubuntu/gutsy/+sources/kdebase/+translate
[05:00] <wgrant> Since when does +sources exist?
[05:01] <wgrant> Isn't it +source?
[05:01] <StevenK> I thought so.
[05:02] <wgrant> Is anyone still running natty?
[05:03] <wgrant> Ah, I have a VM.
[05:04] <wgrant> Natty's Firefox still uses SP:+translate :(
[05:04] <wgrant> liblaunchpad-integration was fixed years ago.
[05:04] <wgrant> So we can't drop the redirect yet.
[05:05] <wgrant> And Firefox to this day uses https://launchpad.net/distros/ubuntu/oneiric/+sources/firefox/+gethelp
[05:05] <wgrant> Should probably fix that before Precise locks us into supporting that triply deprecated URL for another 5 years.
[05:05]  * wgrant files.
[05:08] <wgrant> I guess we can SRU it away in a few weeks, too.
[05:10] <wgrant> jtv: What's the best view to link to for source package translations? SP:+translations?
[05:10] <wgrant> +translate is clearly deprecated, but I don't know if there's something better.
[05:11] <StevenK> wgrant: At least it doesn't use edge :-P
[05:11] <jtv> wgrant: was +translations that complete rewrite of the view that we didn't quite complete about 2 years ago?
[05:11] <wgrant> jtv: +translate redirects to +translations now
[05:14] <jtv> 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] <jtv> To verify that, you could dig up the history to see if the views ever existed side by side.
[05:15] <jtv> With very similar class names.
[05:15]  * jtv digs up timing information
[05:19] <jtv> wgrant: they'd probably have existed side by side in early 2010.
[05:19] <wgrant> jtv: Aha, thanks.
[05:19] <wgrant> +translations looks to be the way to go.
[05:20] <jtv> Speaking purely aesthetically, I'm not entirely happy with that.  It's pretty much all “translations,” isn't it?
[05:20] <wgrant> Hmm?
[05:20] <wgrant> The subdomains are probably not long for this world.
[05:21] <jtv> Arguably one could call just about any level of navigation to that page "translations."
[05:21] <wgrant> Well, I gues.
[05:21] <jtv> The things I like about +translate are its brevity and its specificity.  OTOH it doesn't quite cover translation review.
[05:21] <wgrant> s
[05:21] <wgrant> But we also have +answers, +bugs, +questions, +branches
[05:22] <wgrant> Er, not +answers, that's +questions.
[05:22] <wgrant> But you get the idea.
[05:23] <jtv> True.  But with translations, we have extra layers of granularity: source package or product series; template; po file; individual translated message.
[05:23] <jtv> The latter would be +translation if anything, but the rest are all “the translations for…” at some aggregation level.
[05:24] <wgrant> Sure.
[05:24] <wgrant> +translations is a list of translations.
[05:24] <wgrant> Seems to make sense :)
[05:24] <StevenK> If your membership does expire, we'll send you one more message to let
[05:24] <StevenK> you know it's happened.
[05:24] <StevenK> LIES
[05:24] <wgrant> StevenK: It's true.
[05:24] <wgrant> It just doesn't tell you about the intervening 6 messages before the expiry.
[05:25] <StevenK> It should
[05:25] <StevenK> "By the way, we'll spam you every day until you fix it, you dork."
[05:26] <StevenK> wgrant: Can you review https://code.launchpad.net/~stevenk/launchpad/better-error-open-owner/+merge/83550 ?
[05:27] <jtv> wgrant: anyway, de gustibus and all that.  Maybe the only important question is whether a new URL with an extra "/translations/" in the path (to replace the hostname) will look ridiculous.
[05:27] <StevenK> Why would do that if we don't need to?
[05:28] <jtv> I thought we were getting that?
[05:29] <wgrant> There's one ambiguous view name in the entire application, DistroSeries:+admin.
[05:29] <wgrant> At this stage I'm just flattening everything into mainsite, without changes names.
[05:29] <wgrant> The facet menu will link to +translations, +bugs, etc.
[05:29] <wgrant> Instead of the default view on the relevant vhost.
[05:29] <jtv> No clashes?
[05:29] <wgrant> Only DistroSeries:+admin.
[05:30] <wgrant> I was quite impressed.
[05:30] <wgrant> We've been on separate layers for more than 5 years.
[05:30] <wgrant> But have only made effective use of the separation *once*.
[05:32] <wgrant> StevenK: Is there really no better way?
[05:32] <StevenK> wgrant: For the isinstance garbage?
[05:32] <wgrant> For raising a sensible error.
[05:33] <wgrant> Rather than deleting bits of self.errors.
[05:33] <StevenK> The delete is not needed, that was to make the test cleaner.
[05:33] <wgrant> Even so.
[05:33] <wgrant> There has to be a better way.
[05:34] <wgrant> Also, that error message is silly.
[05:34] <wgrant> It shouldn't include the project name, and it should say what makes a person or team valid.
[05:36] <StevenK> wgrant: "You must choose a person or a Moderated/Restricted team to be the owner."
[05:39] <StevenK> wgrant: I've been trying to come up with a better way and have been failing.
[05:40] <wgrant> I believe we're moving to the term "exclusive team"
[05:40] <wgrant> Talk to Curtis tomorrow.
[05:41] <wgrant> He may also have a suggestion for making the error replacement less nauseating.
[05:48] <wgrant> Bah.
[05:48] <wgrant> stub's DB patch is ahead of mine :(
[05:57] <jtv> Questions: we sync SPPHs from Debian, which then triggers builds in Ubuntu, and process-upload then processes the resulting BPBs/BPRs?  Is that correct?  If so, how does the sync trigger the build?
[05:57] <wgrant> packagecopier
[05:57] <StevenK> We do not copy the SPPH.
[05:57] <StevenK> We copy the SPR, which is linked to a new SPPH.
[05:58] <wgrant> Well.
[05:58] <wgrant> We don't copy the SPR.
[05:58] <wgrant> We reuse the same SPR in a new SPPH.
[05:59] <jtv> Right, that's the part I'm somewhat familiar with—but then what is it that triggers the build?
[05:59] <StevenK> The packagecopier
[06:00] <jtv> I'm looking at that code, but not really finding how the information gets from A to B.
[06:00] <wgrant> It calls SPPH.createMissingBuilds
[06:01] <jtv> Ah!
[06:01] <jtv> And that figures out what still needs building?
[06:01] <StevenK> Yeah
[06:01] <StevenK> Via disgusting code
[06:01] <wgrant> jtv: Didn't you change that code just a couple of weeks ago?
[06:01] <wgrant> getBuildByArch or something.
[06:02] <jtv> One cog, yes.  But unfortunately that doesn't make me familiar with how it fits into this machine.
[06:02] <jtv> Things are so nice and clear-cut when you've got existing, tested code and all you have to do is make it run faster.  :)
[06:03] <jtv> I did see createMissingBuilds while working on that, but I mostly looked at what was relevant to me right then.
[06:03] <wgrant> Hahahah getBuildByArchs tested?
[06:03] <wgrant> A bit, yes.
[06:03] <jtv> The painful reality is that for me, soyuz and the build system have too many concepts for the "ah, I know where this bit goes" to happen spontaneously.
[06:04] <jtv> Actually I think it was called directly quite a few times in a doctest.
[06:05] <jtv> Most of the coverage was indirect though.
[06:09] <jtv> wgrant: I guess then that, to reproduce the bug about unwanted notifications to Debian maintainers, I can proceed as follows:
[06:10] <jtv> Publish a package, with a maintainer.
[06:10] <jtv> Sync it to another distro.
[06:10] <jtv> (Well, archive I suppose)
[06:10] <jtv> Run createMissingBuilds on the new SPPH.
[06:11] <jtv> Then… straight to the upload processor, and sabotage it somehow so that the binary package gets rejected?
[06:12] <wgrant> Right.
[06:12] <jtv> So the BPB is an input to the upload processor?
[06:12] <wgrant> Yes.
[06:12] <wgrant> It usually takes it as an argument.
[06:12] <jtv> Ahhh that's where I was lost.  Thanks for explaining that.
[06:13] <jtv> It actually sounds pretty simple now, but I was stuck for ages.
[06:13] <jtv> (The test we _thought_ I could just twiddle a bit to get the same result didn't seem to, and it relied too much on implicit data creation to make it easy to figure out why)
[06:16] <wgrant> Is the Julian back today?
[06:27] <jtv> I think I'll prepare an NDT rollout request so it's ready to go on LPS as soon as the Q/A blockage clears.
[08:20] <bigjools> morning all
[08:21] <lifeless> zomg its alive
[08:28] <bigjools> it will die under 3k5 emails
[08:40] <lifeless> poolie:  https://code.launchpad.net/~python-fixtures/python-zope-fixtures/trunk probably has the fixture you wanted the other day, now.
[08:41] <adeuring> good morning
[08:50] <lifeless> poolie: I have a suggestion for another split out if you like
[08:50] <lifeless> poolie: ec2*
[08:51] <lifeless> poolie: possibly into lp-dev-tools (or whatever it is called - it exists already)
[08:51] <lifeless> poolie: [I don't mean lptools]
[08:53]  * wgrant deletes vostok
[08:55] <lifeless> \o/
[08:55] <lifeless> if it had templates and functionality, I'd be sad.
[08:59] <StevenK> wgrant: Can you delete delayed copies while you're at it?
[08:59] <wgrant> Sadly not.
[09:00] <StevenK> Some good perms for copyPackages() would be a nice start.
[09:00] <bigjools> I am working on PCJs for PPAs
[09:00] <bigjools> then we can remove delayed copies
[09:01] <wgrant> Well.
[09:01] <wgrant> We also need to sort out permissions for ubuntu-security.
[09:01] <wgrant> But yes.
[09:13] <mrevell> Hello
[09:22] <nigelb> Morning mrevell :)
[09:53] <allenap> mrevell: Re. danhg's email, are you happy to sort out the notifications for a translations-related downtime tomorrow at 1000 UTC?
[09:58] <mrevell> allenap, Yeah, I'll do that now.
[09:58] <mrevell> allenap, Same deal as before?
[10:01] <allenap> mrevell: Yep. The only thing you might want to add is that this has been rescheduled from last week.
[10:02] <mrevell> allenap, Sho thang. Okay, I shall dent, Tweet, email and bloggerise right this instant.
[10:02] <allenap> mrevell: Ta dude.
[10:26] <lifeless> argh ilbqtwebkit weekly dbg builds of 200MB
[10:27] <lifeless> my disk, my disk, my kingdom for some disk
[10:28] <bigjools> bad time to need disk :)
[11:27] <wgrant> rvba: Thanks.
[11:27] <rvba> welcome
[12:49] <rvba> wgrant: in your branch distroseries-translations-admin, I'm not sure I understand why you removed the layer declaration in lib/lp/translations/browser/configure.zcml … ? Can you explain why you did that? (line 10 of the mp)
[12:51] <wgrant> rvba: Ah, that's to finish off https://code.launchpad.net/~wgrant/launchpad/delayer-views
[12:52] <rvba> wgrant: ok, thanks for explaining.
[13:03] <rvba> Morning benji.
[13:04] <benji> mornin' rvba
[13:04] <rick_h_> morning all
[13:07] <rvba> benji: in the queue: 3 branches. The first one (jtv's fix for 717969) will be reviewed by Julian, the second one (Martin's) is really WIP because we need to figure out if we really want that.
[13:08] <benji> rvba: cool, thanks for the info
[13:08] <rvba> About the third one: there is a discussion ongoing between Rob and Jeroen so I did not touch it…
[13:28] <mrevell> Any Orange squadders around?
[13:28] <mrevell> rick_h_, hey
[13:44] <rick_h_> mrevell: yes
[13:44] <mrevell> rick_h_, Hey, do you know when the spinner for custom bug listings might go live on production? If you don't know, no worries.
[13:45] <rick_h_> mrevell: no, abentley is waiting to get some feedback on the goal I think from deryck, but that's a bit delayed atm.
[13:45] <rick_h_> speak of the devil
[13:45] <mrevell> aha :)
[13:45] <rick_h_> I think there might be more more huw involvement
[13:45] <mrevell> Thanks rick_h_
[13:45] <rick_h_> requested as well, checking the email that went around this weekend
[13:45] <nigelb> g37
[13:45] <nigelb> urgh
[13:46] <abentley> rick_h_: missed the context.
[13:46] <mrevell> rick_h_, Yeah, Deryck asked huw for some help with aligning items vertically.
[13:46] <rick_h_> abentley: mrevell is asking about the spinner for the custom bug listings
[13:46] <mrevell> abentley, I was just wondering if we had an ETA on the spinner.
[13:47] <abentley> mrevell: We have our normal spinners ready for QA.  They'll be replaced with deryck's spinner, hopefully this week.
[13:47] <mrevell> Great!
[13:47] <mrevell> Thanks abentley
[13:47] <abentley> mrevell: np
[14:01] <rvba> benji: could you please review https://code.launchpad.net/~rvb/launchpad/builders-timeout-bug-887078-eager-load3/+merge/83576
[14:01] <benji> rvba: sure
[14:07] <mrevell> abentley, In the comments to bug 894736 bryceh suggests that milestones, people, etc should be clickable and that clicking one of them should narrow the scope of the search. So, if I see abentley as a reporter, and then click abentley, I'd get a revised listing of bugs that met my original search criteria, kept the ordering I chosen but were limited to those where abentley was the reporter. That's out of scope for
[14:07] <mrevell>  this project but do you have a rough idea of how much work it'd take to implement that?
[14:07] <_mup_> Bug #894736: People not linked on bug listing <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/894736 >
[14:09] <abentley> mrevell: I'd guess a week, but it depends on whether we'd have to do any work on the backend, or only support filtering by fields already supported in advanced search.
[14:09] <mrevell> Great, thanks abentley.
[14:09] <mrevell> Firmly out of scope :)
[14:11] <abentley> mrevell: I'm also not sure that's the best way to implement such filtering.  It could be quite inconvenient to find the first instance of a milestone in order to filter by it, for example.
[14:17] <mrevell> abentley, Hmm, we can offer other ways to filter by milestone. Of course, this is firmly in the territory of reworking advanced search. I'm also not sure it chimes with my experience of using Amazon search. I'll reply on the bug.
[14:30] <abentley> rick_h_: standup?
[14:31] <rick_h_> abentley: ping, heads up, issues with headset for stand up
[14:31] <rick_h_> ugh, I can record with audacity, but can't get mumble to use it
[14:31] <abentley> rick_h_: ack
[14:31] <abentley> rick_h_: and ick
[14:31] <rick_h_> think  I've entered pulse black hole somewhere
[14:44] <abentley> rick_h_: bzr+ssh://bazaar.launchpad.net/~deryck/launchpad/buglists-loading-885272/
[14:44] <rick_h_> ty
[14:49] <rvba> Thanks for the review benji.
[14:49] <benji> rvba: my pleasure
[14:54] <rick_h_> abentley: hah, portable mic has a mute hardware button doh!
[14:54] <rick_h_> will be better tomorrow
[14:54] <abentley> rick_h_: hehe.  cool.
[14:59] <sinzui> jcsackett, does allhands.canonical.com show that I modified your objectives last week? Can your accept them?
[15:04] <abentley> gary_poster: If I want to find out the name of the current view, should I iterate through getGlobalSiteManager().registeredAdapters() ?
[15:04] <jcsackett> sinzui: it does; i have two tasks showing modified objectives. one shows "registry" competency, one has "code" competency. i confirmed on the task with "code" since registry wasn't something we discussed.
[15:04] <jcsackett> i'm not sure what to do about the now open task with the (seemingly?) wrong objectives in it.
[15:05] <sinzui> jcsackett, do you still have bug domain? maybe I pasted over it?
[15:06] <jcsackett> sinzui: in the task with objectives i accepted, there was bugs, code, and ui stuff--all things we agreed on recently. the other had bugs, registry, and ui stuff.
[15:06] <sinzui> I see them now.
[15:07] <gary_poster> abentley, that would do the trick, and an obvious was to do it does not leap to mind.  (I thought of and discarded another approach)
[15:07] <abentley> gary_poster: Cool, thanks.
[15:08] <sinzui> jcsackett, I think I accepted your acceptance. Do you need to confirm that you same my acceptance?
[15:08]  * sinzui never knows if allhands is messing with his head
[15:08] <jcsackett> sinzui: i have countersigned.
[15:09] <jcsackett> sinzui: is there a way to delete a task on allhands? because i still have the redundant "check objectives" task.
[15:09] <sinzui> Maybe there is a delay. I did not see your acceptance at first
[15:11] <sinzui> jcsackett, I am confused my the status of https://bugs.launchpad.net/launchpad/+bug/893982 Are all the parts in place to QA it?
[15:11] <_mup_> Bug #893982: loggerhead privacy ribbon doesn't have pad lock icon <branches> <disclosure> <exploratory-testing> <privacy> <ui> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/893982 >
[15:12] <jcsackett> sinzui: yes, i had a note to qa it this morning. doing so now.
[15:50] <jcsackett> sinzui: so, the bug is fix committed, but there's some weirdness as far as how to track it.
[15:50] <jcsackett> sinzui: another branch (not one of mine) bumped the version of loggerhead that lp is using, which gets my loggerhead changes.
[15:50] <jcsackett> should i just link that branch to this bug as well?
[15:51] <jcsackett> kind of messes up links, since said branch is entirely incidentally grabbing my changes.
[15:52] <sinzui> jcsackett, only if that branch is being landed. Did that branch cause a version confusion?
[15:56] <jcsackett> sinzui: the branch that bumped loggerhead has landed and is also qa-ok. it is 14383. it has not caused any confusion, my loggerhead-bump branch didn't land, and then flacoste noticed the other one had landed and rejected mine to avoid any such confusion.
[15:57] <sinzui> jcsackett, I do not think the branch needs linking unless you need the bug reset to qa-needstesting when the branch is on qastaging.
[15:57] <jcsackett> sinzui: ok. that's what i thought as well.
[15:57] <jcsackett> sinzui: then, all is well, bug is qa-ok fix-committed. i'll update kanban.
[16:02] <sinzui> thank you
[16:11] <rvba> benji: Can you please have a look at https://code.launchpad.net/~rvb/launchpad/bugs-timeout-bug-892820/+merge/83631 ?
[16:11] <benji> rvba: sure
[16:12] <rvba> thx
[16:21] <gary_poster> abentley (since deryck is out today), dunno if this is helpful to highlight here, but I just triaged 897242 and 897277 as "bug-columns" bugs.
[16:22] <abentley> gary_poster: thanks.
[16:22] <gary_poster> welcome
[16:33] <abentley> gary_poster: registeredAdapters iterates through AdapterRegistration, but AdapterRegistration doesn't seem to provide the adapter class, only a factory function, so I don't see how I can look up the view name.
[16:35] <abentley> gary_poster: nm, the problem is that it's obfuscated behind SimpleViewClass.
[16:39] <gary_poster> abentley, yeah, I wondered if I should warn you about that :-/
[17:03] <nigelb> 300 critical bugs? or is it 900? :P
[17:28] <rick_h_> abentley: adeuring going in search of food, bbiab
[17:28] <abentley> rick_h_: ack
[17:28] <adeuring> rick_h_: enjoy lunch
[18:09] <rick_h_> abentley back fyi, the spinner stuff makes some sense, though now sure how he means to "use" it in the actually ajax calling code.
[18:30] <abentley> rick_h_: cool.
[18:30] <abentley> rick_h_: Since we have spinner support in stable, you should be able to merge that and hook it up pretty easily.
[18:31] <rick_h_> cool, will merge this up with devel then and see if I can make it work out
[18:32] <abentley> rick_h_: I think you'll just need to replace the implementation of ListingNavigator.set_pending.
[18:32] <rick_h_> abentley: ok, looking
[18:52] <rick_h_> abentley: I don't suppose there's any way around creating a bunch of fake bugs in my dev checkout locally to see/tests out this spinner stuff?
[18:53] <abentley> rick_h_: there are already fake bugs, and you can force the batch length unnaturally low by specifying the "batch" query parameter (an int).
[18:54] <rick_h_> ah, ok cool. that helps
[18:55] <abentley> I created a bunch of fake bugs automatically.  I can show you later.
[18:55] <rick_h_> abentley: yea, wasn't sure if there was a helper or a specific project with more bugs that would page
[18:56] <rick_h_> setting batch=2 breaks the JS for me. get_current_batch returns undefined. Looking
[19:45] <gary_poster> hey lifeless.  Are you already aware of some internal service errors on the oops tool (https://lp-oops.canonical.com/oops.py/?oopsid=6e5e984a017534cb393e47e50b93fe95 for example)?  I don't know the current log/dev story for the oops tools and am happy to leave you to it since you are working in that neck of the woods--OTOH I'm also willing to dig in if desired
[19:57] <abentley> matsubara: Are you sure navigation is working for you on chromium, but the spinner is not working?
[19:57] <abentley> matsubara: the symptom I see on chromium is that navigation is not working at all, which of course means the spinner never starts.
[19:57] <matsubara> abentley, I meant the spinner is not working on chromium. If I click any of the sort wdigets, the list is sorted but I get no feedback
[19:58] <matsubara> abentley, and you're correct, the batch navigation doesn't work on chromium either
[19:58] <rick_h_> abentley: nothing works for me on chrome
[19:58] <rick_h_> I'm debugging now, I've gotno next state
[19:58] <abentley> matsubara: are you sure the list is sorted on chromium?  It's not for me.
[19:59] <rick_h_> since chrome pops history on page load, checking to see if the model gets backed off or osmething
[19:59] <matsubara> abentley, yes, it takes awhile but it's sorted
[20:00] <matsubara> abentley, Chromium 15.0.874.106 (Developer Build 107270 Linux) Ubuntu 11.10
[20:00] <matsubara> it seems batching works too, just takes some time to update (no spinner though)
[20:01] <matsubara> oh, scratch that. I'm looking at the wrong place
[20:01] <rick_h_> matsubara: ok, that matches me then
[20:02] <matsubara> ok, on qastaging with listing pre-fetching and dynamic bug listing enabled I get no batch nav, no sorting and no spinner
[20:04] <abentley> matsubara: So I suspect this is not a bug in the spinner at all, but a bug in the new History-based model code.
[20:05] <rick_h_> abentley: right, the way the batches are indexed isn't coming out in chrome it looks like
[20:05] <rick_h_> abentley: the ["-importance", xxx] as a key to an object?
[20:06] <abentley> rick_h_: right.
[20:06] <rick_h_> so get_current_batch ends up returning undefined and blowing up getting anything from there
[20:09] <abentley> rick_h_: Yes, that's how it looks.
[20:11] <wgrant> Is this broken on prod now?
[20:12] <rick_h_> wgrant: no, doesn't look like it
[20:16] <abentley> wgrant: my theory is it's broken by r14385
[20:18] <wgrant> abentley: Have you tried reverting it locally?
[20:18] <abentley> wgrant: doing that now.
[20:19] <abentley> wgrant: Yes, reverting it locally seems to work.
[20:19] <wgrant> OK. Do we turn the beta off for a few hours and deploy, or add a second revert and deploy tomorrow?
[20:22] <abentley> wgrant: I was going to do a rollback.
[20:23] <wgrant> We need to roll it back regardless, but do we care enough about preserving the beta to delay deployments for another day...
[20:25] <abentley> wgrant: Not sure I agree.  If we turn off the beta, there isn't the same urgency to do a rollback.
[20:25] <wgrant> I guess.
[20:30] <abentley> wgrant: I don't know which deployments are key here.  We could deploy 14384 or we could turn off dynamic bug listings and deploy 4395.
[20:30] <abentley> s/4395/14395
[20:33] <abentley> flacoste: We have bugs in the feature that prevent us from deploying anything after r14384.  wgrant suggests we might turn off the feature in order to deploy more stuff.  Thoughts?
[20:41] <jcsackett> benji: could i get a review of https://code.launchpad.net/~jcsackett/launchpad/fancy-filebug/+merge/83636
[20:41] <benji> jcsackett: sure
[20:41] <jcsackett> thanks!
[20:50] <flacoste> abentley: what's the issue with 14385?
[20:50] <abentley> flacoste: It breaks navigation in Chromium.
[20:50] <flacoste> would be nice to have a browser scope selector :-)
[20:51] <flacoste> browser:chromium 0
[20:51] <flacoste> anyway, let's turn the beta off for a day then
[20:51] <lifeless> bah, missed gary
[20:51] <abentley> flacoste: Cool.
[20:52] <flacoste> abentley: 14392 is also bad?
[20:53] <abentley> flacoste: Yes.  Not my proudest day :-).  It breaks navigation on the alternate listings for a Person, such as Commented Bugs.  I landed a rollback this morning, but I don't think it's in stable yet.
[20:54] <flacoste> abentley: we should put out a comment on the blog post and identi.ca that the beta is disabled for a day or two though
[20:55] <abentley> flacoste: I do have an actual fix for 14392 nearly completed, but I just found out about 14385.
[20:59] <flacoste> abentley: another possibility would be to simply leave the feature on
[20:59] <flacoste> and deploy anyway
[21:00] <flacoste> if it was easier to turn the feature off, that would probably the best thing to do
[21:00] <wgrant> abentley: Do you know what your squad's plans for +bugs-index are?
[21:01] <abentley> flacoste: I think we should try to avoid breaking all our beta users who use Chromium.
[21:01] <wgrant> (that's the fairly pointless page with the top-10-hot-bugs listing on eg. https://bugs.launchpad.net/launchpad)
[21:02] <flacoste> wgrant: they are replacing it with a real listing
[21:02] <flacoste> i think
[21:02] <flacoste> iirc
[21:02] <abentley> wgrant: It seems likely we'll make it the same as the productgroup index page, but we haven't investigated the specifics yet.
[21:02] <flacoste> abentley: right
[21:02] <wgrant> abentley: Right, which is just +bugs. That would make my life much easier.
[21:02] <abentley> wgrant: It will have the same bug listings as the other pages.  Details to come.
[21:03] <wgrant> abentley, flacoste: If there was a checkbox for people to opt-out of the beta easily, I'd say leave it on. Since there isn't, I think we should turn it off until it's fixed.
[21:03] <flacoste> agreed
[21:04] <abentley> wgrant: Such a checkbox was originally part of the plan, but we didn't have time.
[21:04] <wgrant> abentley: We need a general solution, anyway.
[21:04] <wgrant> poolie and I have discussed it vaguely.
[21:05] <wgrant> abentley: I suspect the easiest way to fix +bugs-index is just to port a few things across to +bugs (mostly just displaying a warning when the product doesn't have bugs enabled, I believe) and then setting +bugs as the default.
[21:06] <benji> jcsackett: the notification_array.join(' ') bit is kinda funny; how about something like http://paste.ubuntu.com/752973/
[21:06] <jcsackett> benji: sure.
[21:09] <jcsackett> benji: that's pushed up now.
[21:12] <benji> jcsackett: looks good
[21:12] <wgrant> abentley: So, we're OK to deploy despite the two qa-bads?
[21:13] <abentley> wgrant: Yes.
[21:13] <wgrant> abentley: Great, thanks.
[21:14] <abentley> flacoste: I am trying to update the blog, but I cannot log in.  Every time I try, it just prompt me to log in again.
[21:14] <flacoste> abentley: weird, if you have the text, i can past put it in
[21:15] <jcsackett> benji: i have another review, if you have time. very short: https://code.launchpad.net/~jcsackett/launchpad/404s-also-private/+merge/83639
[21:16] <benji> jcsackett: sure
[21:16] <abentley> flacoste: "Update: we have temporarily suspended the beta, but we'll have it back in the next day or so."
[21:18] <benji> jcsackett: done, I included a -- possibly nonsensical -- thought that ocurred to me as well
[21:19] <jcsackett> benji: it would make sense, but in this context we actually know the branch exists, or we would have encountered earlier errors.
[21:19] <benji> k
[21:25] <Noldorin> hi poolie
[21:25] <Noldorin> has Markdown support landed on LP yet?
[21:27] <abentley> flacoste, wgrant: rollback is on devel, as r14404
[21:27] <wgrant> abentley: Thanks.
[21:42] <lifeless> sinzui: sorry for rabbiting on :)
[21:42] <sinzui> lifeless, your explanation was informative. I am glad you have thought about it
[21:50] <flacoste> abentley: updated
[21:51] <abentley> flacoste: thanks.
[21:54] <Noldorin> anyone else besides poolie know?
[22:01] <flacoste> Noldorin: it's landed, but i don't think it's deployed yet
[22:01] <flacoste> and if it's deployed it's not enabled for sure
[22:03] <Noldorin> flacoste, ah ok. i'm not really familar with the launchpad deployment process. are "merged", "landed", "deployed", "enabled" all separate steps in that order?
[22:03] <flacoste> Noldorin: sorry, about the jargon
[22:03] <flacoste> merged and landed are synonymous
[22:03] <flacoste> the branch was merged in trunk
[22:04] <flacoste> we deploy from trunk several times a week
[22:04] <Noldorin> that's what i thought
[22:04] <Noldorin> ah, got it
[22:04] <Noldorin> flacoste, and what does it take for the feature to get enabled?
[22:04] <flacoste> "enabled" refers to some features that we "feature flag"
[22:04] <flacoste> basically, they have a control switch
[22:04] <flacoste> for example, the new bugs listing
[22:04] <flacoste> the switch is on only for certain users (members of the beta team)
[22:05] <Noldorin> ah okay, that's what i was wondering about
[22:05] <Noldorin> so it gets beta-tested live first
[22:05] <flacoste> and earlier, we turned it off because of problems related to the code that is being deployed
[22:05] <Noldorin> then enabled for the public once stable
[22:05] <Noldorin> i guess
[22:05] <flacoste> yes, that's the idea
[22:05] <Noldorin> flacoste, sounds good. thanks for explaining :-)
[22:05] <flacoste> but it really depends on the feature
[22:05] <flacoste> for example, given the limited markdown functinality
[22:05] <Noldorin> i'm supposing that for a simple(ish) feature like Markdown support, it should only be a week or two before enabling
[22:05] <flacoste> we might just turn it on for everybody
[22:06] <Noldorin> cool
[22:06] <flacoste> and turn it off if any problems arise
[22:06] <lifeless> Noldorin: this particular case needs a security audit of the markdown library first
[22:07] <Noldorin> lifeless, hasn't that already happened?
[22:07] <lifeless> no
[22:07] <Noldorin> does it take long?
[22:08] <lifeless> depends on the code size
[22:08] <lifeless> time etc
[22:08] <lifeless> not really a question that can be answered ;0
[22:08] <Noldorin> lifeless, well, not unless you're the person doing the review :-P
[22:08] <lifeless> even if you are
[22:08] <Noldorin> well i debate that
[22:08]  * lifeless shrugs
[22:08] <Noldorin> if you are, then you ought to have a good idea
[22:08] <Noldorin> of what it should take
[22:08] <lifeless> I'll be doing part of it
[22:09] <lifeless> I don't know how long it will take.
[22:09] <Noldorin> not a perfect idea
[22:09] <Noldorin> lifeless, well have you looked at the code for the lib yet?
[22:09] <lifeless> you can tell me I should know, but I assert that I don't.
[22:09] <lifeless> no, I haven't.
[22:09] <Noldorin> don't be so defensive, i'm not telling you that you should know :-P
[22:09] <Noldorin> i'm speaking in hypothetical terms here
[22:09] <Noldorin> well if you haven't read the code yet, i certainly wouldn't expect it
[22:09] <lifeless> I'm not being defensive :)
[22:09] <Noldorin> if you had on the other hand, then yes i *might*...
[22:10] <Noldorin> it seemed like it, but okay sure
[22:16] <poolie> hi all
[22:17] <poolie> flacoste, adding a 'user-agent' feature scope should be pretty easy
[22:17] <poolie> or perhaps one that just generically matches the request header
[22:19] <flacoste> yeah, that was my guess
[22:20] <StevenK> sinzui, wallyworld_, jcsackett: https://code.launchpad.net/~stevenk/launchpad/better-error-open-owner/+merge/83550
[22:49] <StevenK> Rargh, rf-get should run make clean before updating just to stop all these conflicts.
[23:02] <StevenK> poolie: 71 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
[23:02] <StevenK> poolie: I think we should freshen the image.
[23:03] <poolie> already?
[23:03] <poolie> which image did you use?
[23:04] <StevenK> 522
[23:04] <poolie> hm, current is supposed to be 523
[23:04] <poolie> i wonder why you don't see it
[23:04] <StevenK> Probably because I didn't merge devel. This may lead to test failures.
[23:04] <poolie> ...
[23:04] <poolie> it shouldn't be necessary
[23:05] <poolie> it is looked up on the network
[23:05] <poolie> what does 'ec2 images' show, run from devel
[23:05] <StevenK> 522, wgrant
[23:05] <poolie> ok
[23:05] <poolie> it was private
[23:05] <poolie> despite i thought giving the option to make it public
[23:06] <poolie> StevenK, try again?
[23:06] <poolie> even just 'ec2 test --trunk' to see what happens
[23:06] <StevenK> Now 523 shows up
[23:06] <StevenK> However, that description is massive.
[23:06] <poolie> 50 bytes!
[23:07] <poolie> do you know how much those things cost?
[23:07] <StevenK>   523  ami-f721e99e  957911449157  mbp          launchpad ec2test created 2011-11-23 08:32:11 UTC by 'mbp@canonical.com' on joy
[23:07] <StevenK>   522  ami-7fa56916  873925794399  wgrant       Created 2011-10-08 00:52:32 UTC
[23:07] <StevenK> It wraps and means it is harder to parse.
[23:07] <poolie> but you know who to blame :)
[23:07] <poolie> anyhow, patches welcome
[23:07] <poolie> lifeless, good idea about splitting out ec2
[23:08] <StevenK> I knew who to blame before! :-P
[23:08] <lifeless> StevenK: doesn't wrap for me :P
[23:08] <poolie> wish you'd told me before i went through pqm to land changes to it :)
[23:08] <StevenK> lifeless: I run in 80x24 like we're SUPPOSED to.
[23:08] <StevenK> :-P
[23:08] <lifeless> StevenK: if god intended you to have a crippled terminal, he would have given you an amber screen
[23:08] <lifeless> :)
[23:09] <StevenK> I was waiting for "The 80s called, they want their terminal dimensions back."
[23:09] <lifeless> The 80s called, they want their catchphrase back.
[23:09]  * lifeless goes meta
[23:09] <StevenK> Anyway, TERM says 'xterm', so it should act like one.
[23:10] <lifeless> StevenK: indeed, 200x50 or so :)
[23:11] <lifeless> no you have me doing history lookups for DEC VS100's
[23:12] <StevenK> Heh heh
[23:13] <lifeless> VS100 - original target for xterm
[23:13] <lifeless> 19" 1088x864 pixels
[23:13] <lifeless> https://docs.google.com/viewer?a=v&q=cache:3At_IEDM3YQJ:www.bitsavers.org/pdf/dec/graphics/VS100_Engineering_Specification_Jun83.pdf+&hl=en&pid=bl&srcid=ADGEEShzKk3TN13uySW6boAVQV9NfXdE7yBdoz9k77EtaSSpAJEZlhwNp-AlqRFIyLwRHnX04fWx1m-S7z6rTZmpMBP2QOIUen3NyC-946yC_hrybqELz0lOuJvrXJ5ENEfXbGj7dlp-&sig=AHIEtbR5d6Vm7ElUXQOozYGhpMEhr64iOA
[23:16] <lifeless> so, > 80x24 :)
[23:20] <lifeless> poolie: does https://code.launchpad.net/~python-fixtures/python-zope-fixtures/trunk have anything you need ?
[23:20] <lifeless> poolie: if it does, I can cut a release now, otherwise I'm planning on waiting a little for additional bits to land
[23:23] <lifeless> anyone want to have a go parsing https://bugs.launchpad.net/launchpad/+bug/897442 ? My brain glitches
[23:23] <_mup_> Bug #897442: maintained packages page not up to date after several weeks <Launchpad itself:New> < https://launchpad.net/bugs/897442 >
[23:23] <poolie> lifeless, um
[23:24] <poolie> i added a new fixture to launchpad's own fixtures.py
[23:24] <poolie> you could copy that out to the separate project
[23:25] <poolie> in r14372 of devel
[23:25] <poolie> i'm not blocking on getting anything else
[23:45] <StevenK> poolie, jelmer: Did you guys have a plan of attack to QA r14397?
[23:46] <poolie> sigh
[23:47] <poolie> iirc that is mostly about an update to the webapp, not the builders?
[23:47] <poolie> so we ought to be able to test it by adding such a recipe on qas ?
[23:48] <StevenK> [r=mbp][ui=none][bug=891928] Update bzr-builder to the latest upstream revision.
[23:48] <StevenK> Fixes:
[23:48] <StevenK>     Bug:891928
[23:48] <StevenK> Since bzr-builder is used on the buildds to build recipes ....
[23:48] <poolie> but that's separate
[23:48] <poolie> that's one of the things that is confusing
[23:52] <poolie> StevenK, i will qa it now
[23:57] <poolie> StevenK, 'qa' is so confused
[23:57] <poolie> 'is it fixed' vs 'is it safe'
[23:59] <wgrant> It is "is it safe"
[23:59] <wgrant> It just has a bad name.
[23:59] <poolie> so this fix doesn't work
[23:59] <poolie> but as long as it doesn't obviously regress anything else
[23:59] <poolie> it is probably ok to deploy