[00:00] <wgrant> StevenK: The only ordering differences there are doctests :(
[00:01] <wgrant> StevenK: I wonder if the value already fluctuated, and the test had a buffer built in that my extra line exceeds.
[00:02] <wgrant> StevenK: One way to test that is to decrease the limit by a few and throw it at ec2 two or three times, and see what values come back and which queries differ.
[00:03] <lifeless> interesting
[00:03] <lifeless> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1880F2434
[00:03] <lifeless> 2.5 seconds sql
[00:03] <lifeless> 12 python
[00:03] <lifeless> ><
[00:03] <wgrant> lifeless: You really need to acquire some LOSAs next week.
[00:04] <lifeless> it will help
[00:04] <lifeless> hmm, thats what I was going to do.
[00:06] <wgrant> lifeless: Did you see my review poke?
[00:06] <lifeless> no
[00:07] <wgrant> https://code.launchpad.net/~jameinel/launchpad/loggerhead-disconnect-701329/+merge/48665
[00:07] <wgrant> It is our friendly 16k OOPS bug.
[00:09] <lifeless> done
[00:10] <lifeless> we need a bug, if there isn't one, about the lack of timeout checking on that exception check.
[00:10] <wgrant> lifeless: Because haproxy will kill the connection after a while?
[00:11] <lifeless> wgrant: that or users yes
[00:11] <lifeless> basically we don't have the timeline trigger we do in the zope stack
[00:11] <wgrant> Right.
[00:12] <lifeless> so if the client goes away and we render at 8 seconds in
[00:12] <lifeless> we'll hit a socket error rather than generating a timeout
[00:12] <lifeless> we should record them as oopses, as timeouts
[00:13] <StevenK> Er, wasn't the entire point of the branch to *stop* oops on socket errors?
[00:13] <lifeless> yes, but we shouldn't stop them all
[00:13] <lifeless> its better to land this branch now
[00:14] <lifeless> but we *know* we're discarding valid, important oopses as a result. Its overcorrecting.
[00:14] <StevenK> So, the 16k oops aren't all the haproxy ping?
[00:14] <lifeless> theres two different exception times
[00:14] <lifeless> one is haproxy, a few hundred a day are not haproxy
[00:14] <lifeless> they are all going to go when this lands
[00:15] <StevenK> wgrant: So subunit-diff helped, or you got distracted?
[00:15] <wgrant> StevenK: I used subunit-ls then normal diff.
[00:16] <wgrant> StevenK: There are no significant non-doctest order changes.
[00:18] <StevenK> wgrant: Which means toss it through ec2 again?
[00:22] <wgrant> StevenK: Maybe not.
[00:22] <wgrant> Checking something locally.
[00:26] <wgrant> StevenK: Try running the whole test_archive_packages locally.
[00:26] <wgrant> It seems to succeed.
[00:26] <wgrant> Can you confirm?
[00:32] <StevenK> wgrant: YEs
[00:32] <wgrant> StevenK: Throw it at ec2 again, and lp-land if it fails again.
[00:32] <StevenK> So .... yay
[00:33] <wgrant> I can debug it locally from here.
[00:42] <lifeless> wgrant: had you done a test run with your eager loading person patch
[00:47] <timrc> StevenK: Hey... I followed your example in https://bugs.launchpad.net/launchpad/+bug/440652/comments/4 using changing out values 'ppa-foo' and 'edge in login_with() and my e-mail for getByEmail().  When I do a dir(me), I do not see createPPA... was wondering if you may have an idea why
[00:47] <_mup_> Bug #440652: Allow creation of PPAs via API <api> <bad-commit-11820> <lp-soyuz> <oem-services> <ppa> <qa-ok> <Launchpad itself:Fix Released by stevenk> < https://launchpad.net/bugs/440652 >
[00:50] <wgrant> lifeless: No.
[00:50] <wgrant> StevenK: Actually, if it fails ec2 again and I haven't landed a fix yet, increase the limit in the test by 1 and lp-land.
[00:51] <wgrant> Just to be safe.
[00:51] <lifeless> wgrant: ah. Well, I may break ec2 then
[00:52] <wgrant> lifeless: Oh?
[00:52] <wgrant> It's very unlikely to break anything...
[00:53] <lifeless> adds another query to bug page loading
[00:53] <lifeless> some of the scaling tests are exactly on the minimum query count
[00:53] <StevenK> timrc: Having a look
[00:53] <wgrant> lifeless: Only if there are no comments.
[00:53] <wgrant> No comments with people other than the reporter, I guess.
[00:54] <wgrant> StevenK: Ah, I see the issue.
[00:54] <lifeless> it doesn't discard things in the storm cache from the queyr
[00:54] <lifeless> so it will query them all
[00:54] <StevenK> wgrant: With test_source_query_counts?
[00:54] <wgrant> StevenK: Yes.
[00:54] <wgrant> StevenK: It was already fluctuating, and my change made it exceed the buffer.
[00:54] <wgrant> StevenK: The first webservice test does a SELECT secret FROM secret
[00:54] <wgrant> Subsequent ones do not.
[00:55] <StevenK> I did see that in the traceback.
[00:55] <wgrant> Will fix properly after lunch -- increment the buffer and lp-land for now.
[00:56] <StevenK> wgrant: The branch has been in ec2 for 10 minutes :-(
[00:56] <wgrant> Ah.
[00:57] <wgrant> In happier news, the mirror prober has now shut up.
[00:57] <wgrant> In less happy news, lucid_db_lp has librarian-broken again
[00:57] <StevenK> wgrant: I can kill the instance with fire, bump the 42 to 44(?) and lp-land
[00:58] <wgrant> StevenK: 43
[00:58] <StevenK> Or I can just wait
[00:58] <wgrant> But yes, that's a good plan.
[00:58] <wgrant> My change added (626, 626, 'SQL-nostore', 'Transaction completed, status: Active') to the end.
[00:58] <wgrant> That's all.
[00:58] <StevenK> That's a COMMIT or actually something else?
[00:58]  * thumper takes a break
[00:59] <wgrant> I am not entirely sure.
[00:59] <wgrant> Normally it says something like "Committed" or "Doomed"
[01:00] <StevenK> wgrant: Mind you, the branch had 3 other failures, which I've fixed, so not sure that impacts your "use lp-land" comment
[01:00] <wgrant> Ah.
[01:01] <StevenK> timrc: This is strange. The production API doesn't mention createPPA at all.
[01:01] <StevenK> But qastaging does
[01:02] <wgrant> StevenK: I see createPPA in lpnet's apidoc...
[01:03] <StevenK> wgrant: Looking at my api.launchpad.net cached WADL, I can't see it
[01:03] <wgrant> StevenK: What if you move the cached WADL away?
[01:03] <wgrant> Or use devel instead?
[01:06] <StevenK> timrc: Are you using edge or production?
[01:06] <StevenK> wgrant: Still happy for me to kill the instance and lp-land directly?
[01:07] <wgrant> StevenK: If you've fixed the other failures and incremented the value, sure.
[01:10] <StevenK> wgrant: http://pastebin.ubuntu.com/571446/
[01:11] <wgrant> StevenK: If it passes on its own locally, go for it.
[01:11] <StevenK> It does, pushing and landing
[01:11] <wgrant> Thanks.
[01:12] <wgrant> I will fix the test infrastructure to clear the session machinery's secret cache, I think.
[01:12] <StevenK> Rargh, lp-land uses edge
[01:12] <StevenK> EDGE!
[01:15]  * wgrant → lunch
[01:15] <timrc> wgrant, StevenK: my apologies, I had to dip out
[01:15] <timrc> StevenK: I was testing with edge
[01:17] <StevenK> timrc: I had to delete my launchpadlib cache, but using production I could see createPPA()
[01:17] <timrc> StevenK: okay, let me give it a try
[01:17]  * cody-somerville wondered if it was a cache issue.
[01:18] <StevenK> cody-somerville: I was hoping it wasn't, and my cache of the production WADL was only 24 hours old
[01:18] <cody-somerville> interesting
[01:18] <StevenK> ITYM "disturbing"
[01:20] <timrc> StevenK: okay, switching to production, and it worked as expected
[01:23] <timrc> StevenK: and clearing my cache for edge also worked
[01:24] <timrc> StevenK, wgrant: thanks!
[01:25] <StevenK> timrc: You're welcome
[01:48] <lifeless> hmm
[01:48] <lifeless> is there an ISourcePackage adapter for IDistributionSourcePackage
[01:56] <lifeless> wgrant: btw
[01:57] <lifeless> test_source_query_counts - the expected_count += 1 due to getCurrentSourceReleases can be trivially fixed now.
[01:59] <StevenK> It can?
[01:59] <lifeless> yes
[02:01] <lifeless> StevenK: look at the implementation of DistroSeries.getCurrentSourceReleases
[02:16] <wgrant> lifeless: How does it make sense to adapt a DistributionSourcePackage to an ISourcePackage?
[02:22] <lifeless> get the current series sourcepackage
[02:22] <lifeless> https://bugs.launchpad.net/launchpad/+bug/279513
[02:22] <_mup_> Bug #279513: Distribution source package tooltip in bugtask table shows most recent SPPH in any series <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/279513 >
[02:22] <wgrant> Ah.
[02:25] <lifeless> bunch of code in dsp would be simpler if it indirected to ISourcePackage(self).<same>
[02:26] <lifeless> for instance
[02:26] <wgrant> If you add that adapter then you have to rename it to DistroSeriesSourcePackage.
[02:26] <lifeless> bah
[02:26] <lifeless> whats in a name
[02:26] <lifeless> also the sample data is bong
[02:27] <lifeless> hoary has no publications
[02:28] <wgrant> Yes, the sample data is really bad.
[02:30] <wgrant>   44 IntegrityError: duplicate key value violates unique constraint "tm__potmsgset__language__shared__ubuntu__key"
[02:30] <wgrant> Not ideal.
[02:30] <lifeless> oops?
[02:31] <wgrant> OOPS-1880A1578
[02:39] <wgrant> session_dev=# SELECT secret FROM secret;
[02:39] <wgrant>           secret
[02:39] <wgrant> --------------------------
[02:39] <wgrant>  thooper thpetial theqwet
[02:39] <wgrant> Hah
[02:42] <lifeless> oh noes
[02:42] <lifeless> lp has been hacked
[02:42] <wgrant> I know!
[02:42] <wgrant> lifeless: lib/canonical/launchpad/webapp/session.py, _get_secret is a test isolation issue.
[02:43] <wgrant> I am wondering about a good place to clear that.
[02:44] <lifeless> sec
[02:49] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-279513/+merge/51063
[02:49] <wgrant> lifeless: Looking.
[02:50] <lifeless> so re the secret
[02:50] <lifeless> I've worked around it by doing one request before actual test requiests
[02:50] <lifeless> thats a bit fugly
[02:50] <wgrant> I am tempted to clear it in getUserBrowser.
[02:50] <wgrant> Well, setupBrowser.
[02:50] <lifeless> forcing it on every time?
[02:51] <wgrant> Empty the cache so it is queried for every test.
[02:51] <lifeless> won't help folk doing 2 queries per test
[02:51] <lifeless> what about populating it when the layer is brought up
[02:51] <wgrant> But it will isolate the tests.
[02:51] <wgrant> I guess.
[02:51] <wgrant> Yeah, that might work.
[02:51] <wgrant> Just need to be sure the DB is in place at that point.
[02:52] <LPCIBot> Project db-devel build (392): STILL FAILING in 5 hr 23 min: https://hudson.wedontsleep.org/job/db-devel/392/
[02:52] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12438,
[02:52] <LPCIBot> 12439 included.
[02:53] <thumper> wgrant, wallyworld: update script evolved to http://pastebin.ubuntu.com/571485/
[02:53] <wallyworld> thumper: cool. otp. will look soon
[02:54] <wgrant> thumper: e.name vs e.new_value?
[02:54] <thumper> e.name is the name of the field updated
[02:55] <thumper> e.new_value is the value of the field
[02:55] <wgrant> Oh, right, separate events.
[02:55] <thumper> wgrant: yup, very simple update methods
[02:55] <wgrant> Looks really great.
[02:55] <wgrant> Please deploy it EVERYWHERE>
[02:55] <wgrant> Now.
[02:55] <thumper> wgrant: would you like to review the interesting change?
[02:56] <thumper> wgrant: like Javascript?
[02:56] <wgrant> thumper: I would.
[02:56] <wgrant> I don't know YUI well at all, but I need to learn it.
[02:56] <thumper> wgrant: well... there are three branches here
[02:56] <thumper> wgrant: I've self approved the first one
[02:56] <wgrant> I saw that.
[02:56] <thumper> it changed LP.client.cache -> LP.cache
[02:56] <thumper> and LP.client.links -> LP.links
[02:56] <thumper> and that was it
[02:56] <thumper> the second makes LP.client methods a YUI module
[02:57] <thumper> I was about to self approve, but if you want to take a look, it is mind-numbingly boring
[02:57] <thumper> https://code.launchpad.net/~thumper/launchpad/lp-client-yui-module/+merge/51038
[02:57] <thumper> and 2.2k lines
[02:57] <wgrant> I already had that open, and it is 1.5k lines... has it grown?
[02:57] <wgrant> Hah, it has.
[02:58] <thumper> https://code.launchpad.net/~thumper/launchpad/client-cache-sync/+merge/51049
[02:58] <thumper> that is the intersting one
[02:58] <LPCIBot> Project devel build (469): FAILURE in 5 hr 21 min: https://hudson.wedontsleep.org/job/devel/469/
[02:58] <LPCIBot> Launchpad Patch Queue Manager: [r=jcsackett,sinzui][no-qa] Add a test to prevent new Sphinx errors
[02:59] <thumper> wgrant: where is that bug of yours that says the base branch and deb version get out of date?
[03:00] <wgrant> thumper: Bug #721064
[03:00] <_mup_> Bug #721064: Inline recipe text editor doesn't update the "Debian version" field on the page <recipe> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721064 >
[03:00] <wgrant> I actually thought you'd just laugh and ignore it.
[03:00] <wgrant> I didn't imagine a fix was in progress.
[03:01] <thumper> :)
[03:06] <wallyworld> thumper: looks ok on first read. i think i need to actually wire something up though and experiment to get a full feel for it
[03:08] <wgrant> lifeless: These structural subscription queries upset me.
[03:08] <wgrant> Just looking at some checkwatches OOPSes.
[03:08] <lifeless> there is a bug now
[03:08] <wgrant> SQL queries that are 323 lines long: Australia says no.
[03:14] <lifeless> oh good
[03:14] <lifeless> question:+index is back
[03:18] <thumper> wgrant: I've added a description to the MP
[03:19] <wgrant> Hmm.
[03:19] <wgrant> That LockWarner thing just killed devel for a second time.
[03:19] <wgrant> Maybe not spurious.
[03:20] <wgrant> Well, it seems to at least occur there with far higher frequency than the other places it shows up.
[03:21] <wgrant> I think we should disable that test.
[03:21] <wgrant> lifeless: Do you know why NullBugTask still exists?
[03:22] <wgrant> thumper: hm, why do you redirect on location change?
[03:22] <lifeless> its high frequency
[03:23] <lifeless> we should fix it
[03:23] <thumper> wgrant: ahh... whut?
[03:23] <lifeless> its the same as the oopses we're seeing I think
[03:23] <wgrant> thumper: erm, I mean, why do you reload the page when the web_link changes?
[03:23] <lifeless> wgrant: nullbugtask exists for when someone puts in an invalid context for a bug
[03:23] <wgrant> lifeless: I know that's why it existed.
[03:23] <wgrant> But it doesn't explain why it still exists.
[03:23] <thumper> wgrant: because the current page is now invalid
[03:24] <thumper> wgrant: it doesn't exist any more
[03:24] <thumper> wgrant: it would be a 404
[03:24] <lifeless> wgrant: whats more interesting is 'why isn't the NBT redirect working'
[03:24] <thumper> wgrant: for example, if I change the owner of a recipe
[03:24] <thumper> wgrant: the recipe now has a new url
[03:24] <lifeless> I think this may be related to it being a source package, or something
[03:24] <wgrant> lifeless: There is one case left.
[03:24] <wgrant> lifeless: It is.
[03:24] <wgrant> lifeless: It checks if it's reported in the distribution at all.
[03:24] <wgrant> If it is, it's OK.
[03:24] <wgrant> I am wondering why that is OK.
[03:24] <lifeless> I think this is oversight
[03:25] <wgrant> I hope so.
[03:25] <wgrant> I meant to check with Bugs people about it.
[03:25] <lifeless> gmb muttered words to the effect of 'wtf' when I opened the NBT timeout bug
[03:25] <wgrant> thumper: Can't we update things that reference the base URL and push a new history entry?
[03:25] <wgrant> The AJAX product switcher refreshing the page is really disconcerting.
[03:25] <wgrant> lifeless: Ah, good.;
[03:26] <wgrant> lifeless: 'tis easily destroyed, then.
[03:26] <thumper> wgrant: I'm not sure... can we?
[03:26] <wgrant> Will you murder it?
[03:26] <lifeless> I don't believe you'd meet any objections to nuking it
[03:26] <thumper> wgrant: in a reasonable way?
[03:26] <lifeless> wgrant: no, I'm staying on the top two timeouts
[03:26] <wgrant> thumper: github does it reasonably nicely.
[03:26] <wgrant> Twitter does it awfully badly.
[03:26] <lifeless> I'm going to poke at Branch:+index for a bit, it seems to be running into grief
[03:27] <thumper> wgrant: I'll take a look
[03:28] <wgrant> thumper: See https://github.com/jquery/jquery
[03:28] <wgrant> Click on a directory there.
[03:28] <wgrant> It changes the URL without refreshing the page.
[03:29] <thumper> wgrant: it is refreshing the page, or at least firebug thinks so
[03:29] <wgrant> thumper: Firefox 3?
[03:30] <thumper> yep
[03:30] <wgrant> I guess that doesn't support some new HTML5 API that it needs :(
[03:30] <wgrant> Sad.
[03:30] <StevenK> lifeless: Your forced build failed in exactly the same way ...
[03:30] <lifeless> StevenK: no
[03:30] <lifeless> StevenK: db-devel failed
[03:30] <lifeless> then devel failed
[03:31] <lifeless> devels previous failure was a different error
[03:31]  * lifeless is pretty but not 100% sure that this is what happened
[03:31]  * StevenK checks again
[03:32] <thumper> I am so finishing a little early today
[03:32] <thumper> 6am call, and working through lunch
[03:32] <lifeless> yeah
[03:32] <lifeless> now if only that call was at 7am
[03:32] <StevenK> Yes, I'm right. Both 653 and 654 both failed with the _LockWarner garbage in the middle of the Sphnix test.
[03:33] <wgrant> That's what I thought.
[03:33] <lifeless> ah well
[03:33] <lifeless> 3rd time lucky
[03:33] <StevenK> And if it fails then you might admit there is an issue?
[03:33] <lifeless> if you want to disable it I think thats a reasonable precaution
[03:33] <lifeless> I've already agreed to that, no need to get snarky
[03:33] <lifeless> all intermittent failures are issues
[03:33] <lifeless> there is a bug open on this one
[03:33] <lifeless> marked critical
[03:34] <StevenK> lifeless: You already said I was wrong once ... :-)
[03:34] <lifeless> StevenK: I thought the identical failure was on db-devel
[03:34] <lifeless> hmm
[03:35] <lifeless> wallyworld: do you show bugs in the linked mps you did on branch indexes ?
[03:35] <StevenK> No, db-devel was test_404 and test_old librarian breakage
[03:35] <lifeless> StevenK: thanks for digging
[03:35] <StevenK> In fact, Hudson is failing builds in exactly the same way.
[03:36] <StevenK> actual = "Making output directory...\nException IndexError: IndexError('list index out of range',) in <bound method _LockWarner.__del__ of <bzrlib.lockable_files._LockWarner object at 0x10ea8790>> ignored\n"
[03:36] <wgrant> Huh.
[03:39]  * thumper walks away for today
[03:39] <thumper> branches are up for review
[03:42] <wallyworld> lifeless: yes.
[03:43] <StevenK> lifeless: I thought we had upgraded all of our sourcecode branches? http://pastebin.ubuntu.com/571505/
[03:43] <wallyworld> lifeless: there are a couple of minor enhancements/issue that martin raised. can't recall what they are off hand
[03:44] <wgrant> StevenK: Your local branch is an old format.
[03:44] <lifeless> wallyworld: https://bugs.launchpad.net/launchpad/+bug/710685
[03:44] <StevenK> steven@liquified:.../sourcecode/loggerhead% bzr info
[03:44] <StevenK> Standalone tree (format: unnamed)
[03:44] <_mup_> Bug #710685: Branch:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/710685 >
[03:44] <StevenK> Hm. Orsum
[03:45] <lifeless> wallyworld: *300* bug lookups on Branch:+index pages.
[03:45]  * wallyworld looks
[03:45] <lifeless> wallyworld: I suspect, totally without evidence, your patch.
[03:47] <wallyworld> lifeless: could be me for sure. it was a while ago, but there already was one round of optimisation to avoid the 1+N query problem. could be something else as well. i'll look at it once i finish my current branch
[03:47] <lifeless> wallyworld: you're on maintenance next week
[03:48] <lifeless> wallyworld: if I were you, I'd stay focused on recipes this week to leave them as awesome as possible
[03:48] <StevenK> Hm, what does format: unnamed in bzr info mean?
[03:48] <wallyworld> lifeless: yep. wasn't sure if you wanted it to wait til next week but that suits me fine
[03:57] <lifeless> wallyworld: I was running it up the flagpole to see if it triggered an 'oh yes' or a 'hmm didn't think of that' or a 'its been changed since me cause I checked for that'
[03:58] <wallyworld> lifeless: nothing pops to mind, since work was done to reduce the query count at the time of implementation and i *thought* it was left in a sensible state. something might jump out when i have another look though
[03:59] <lifeless> I've just generated OOPS-1881C305 on https://code.launchpad.net/++oops++/~bzr-pqm/bzr/bzr.dev to get an overview
[03:59] <lifeless> that branch has no linked bugs
[04:11] <wgrant> Oh.
[04:11] <wgrant> OH
[04:11] <wgrant> FFS
[04:11]  * wgrant headdesks repeatedly.
[04:11] <wgrant> REPEATEDLY
[04:11] <wgrant> So. Fucking. Obvious.
[04:11] <wgrant> Garrr
[04:12] <wgrant> The librarian mystery is not so mysterious.
[04:13] <lifeless> wgrant: 'sup
[04:14] <StevenK> wgrant: Is this test_404 and such?
[04:14] <wgrant> StevenK: yes.
[04:14] <StevenK> SHARE!
[04:14] <wgrant> I will have a branch in a sec.
[04:14] <wgrant> You don't want to see it.
[04:14] <wgrant> You will never forgive yourself for not seeing it earlier.
[04:15] <StevenK> Hahaha
[04:16] <wgrant> Now I just have to kick Windmill in the face a few times.
[04:16] <StevenK> Only if you have knives on the bottom of your shoes
[04:20] <StevenK> lifeless: I can't see this bug about Sphinx
[04:20] <wgrant> There's a bug about the _LockWarner issue in general.
[04:21] <wgrant> Sphinx just exposes it better.
[04:21] <lifeless> bug 721166
[04:21] <_mup_> Bug #721166: Tests sometimes fail on EC2 due to _LockWarner garbage <build-infrastructure> <spurious-test-failure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721166 >
[04:22] <StevenK> I'm strongly leaning towards disabling test_docs_build_without_error
[04:23] <wgrant> If it fails again, do it,.
[04:23] <wgrant> It is not Sphinx's issue, but Sphinx seems to expose it reliably... except locally.
[04:23] <wgrant> ... and except on ec2.
[04:23] <StevenK> It's failed twice on BuildBot and once on Hudson
[04:23] <wgrant> Kill it.
[04:24] <StevenK> -    def test_docs_build_without_error(self):
[04:24] <StevenK> +    def DISABLED_test_docs_build_without_error(self):
[04:36] <StevenK> wgrant: Tossing to PQM with "[testfix][rs=stevenk,wgrant] Disable building the Sphinx docs due to spurious failures."
[04:37] <wgrant> StevenK: You're disabling the *test*.
[04:37] <wgrant> Not building the docs.
[04:38] <wgrant> Also, we're not actually in testfix atm, are we?
[04:38] <wgrant> So you'll need QA tags.
[04:38] <StevenK> [rs=stevenk,wgrant][no-qa] Disable the Sphinx docs test due to spurious failures.
[04:39] <wgrant> StevenK: Looks good.
[04:39] <StevenK> Tossing
[04:39] <StevenK> wgrant: Where's this librarian branch?
[04:39] <wgrant> StevenK: Generating a diff.;
[04:40] <wgrant> Description of the Change
[04:40] <wgrant> So it turns out that str.replace()ing integers in a URL with a random port is not such a good idea.
[04:40] <StevenK> *facepalm*
[04:41] <wgrant> Codehosting, you suck.
[04:43] <wgrant> I discounted months ago the idea that there was an obvious issue in the tests themselves, because a subclass worked fine...
[04:43]  * StevenK discovers the branch
[04:43] <wgrant> Diff is mostly there now.
[04:43] <StevenK> I note the branch scanner hasn't run over it yet
[04:44]  * wgrant goes logdiving.
[04:44] <StevenK> It has now
[04:44] <wgrant> The diff took 6 minutes :/
[04:45] <wgrant> lifeless: Still around?
[04:45] <StevenK> wgrant: Why a top level function?
[04:45] <wgrant> StevenK: Because there is no benefit in making it a method.
[04:46] <wgrant> We are not Java.
[04:46] <StevenK> Next question, why weren't they failing locally? :-)
[04:47] <lifeless> wgrant: sup
[04:48] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/fix-librarian-spuriousity/+merge/51068
[04:48] <StevenK> lifeless: I've already reviewed, so you need to review my review
[04:49] <lifeless> so, when the port == the alias, boom
[04:49] <lifeless> yes?
[04:49] <wgrant> lifeless: When the alias is any substring of the port.
[04:49] <lifeless> right
[04:50] <wgrant> I am guessing the ec2 and hudson pids rarely get high enough.
[04:50] <wgrant> And locally the tests are rarely run.
[04:50] <StevenK> OH, it's from the pid?
[04:50] <wgrant> Hm, except it's ports, not pids.
[04:50] <wgrant> Fail.
[04:50] <wgrant> I wonder what the algorithm is.
[04:51] <StevenK> It does seem to hit buildbot more
[04:51] <lifeless> you need a low ephemeral port #
[04:51] <lifeless> and a high lfa id
[04:51] <StevenK> Right
[04:52] <StevenK> Laaaaaaaaaaand it
[04:53] <wgrant> Thanks.
[04:53] <wgrant> If only we could restart test runs.
[04:54] <lifeless> import smalltalk; smalltalk.start()
[04:55] <lifeless> think of the good news
[04:55] <lifeless> if I broke the test suite, we'll see those failures as well
[04:55] <wgrant> What good news? There is still Windmill and _LockWarner.
[04:55] <wgrant> Hah
[04:58] <lifeless> now to figure out why @adapter(IBeforeTraversedEvent) isn't triggering
[04:58] <wgrant> What are you doing and why?
[05:02] <lifeless> ++profile++ on staging
[05:02] <lifeless> we'll miss very early setup
[05:07] <lifeless> oh wow
[05:07] <lifeless> we call set_developer_in_launchbag_before_traversal a few times too many
[05:07] <lifeless> (becaues the event doesn't do what folk think it does)
[05:08] <wgrant> Is it before every publishTraverse?
[05:09] <lifeless> its before each step of traversal, yes
[05:09] <lifeless> I'm going to be using the same event, but explictly handle that case
[05:09] <lifeless> its easier than patching zope
[05:16] <wgrant> I suppose I should exterminate the remaining third of the checkwatches OOPSes.
[05:17] <StevenK> How many OOPSes is that?
[05:18] <lifeless> 3 brazillion
[05:18] <wgrant> It varies.
[05:18] <wgrant> 1000-7000 a day.
[05:18] <wgrant> 15000 in the last three days.
[05:18] <wgrant> 9000 of which are fixed.
[05:20] <StevenK> staging doesn't love me :-(
[05:21] <wgrant> The update failed due to some slony stuff.
[05:24] <wgrant> Speaking of slony.
[05:29] <wgrant>         if not is_ca_available():
[05:29] <wgrant>             raise LayerInvariantError(
[05:29] <wgrant>                 "Component architecture not loaded or totally screwed"
[05:29] <wgrant>                 )
[05:30] <lifeless> wgrant: speaking of fish, monitors ?
[05:32] <wgrant> lifeless: The slony comment was related to the arrival of stub, not the CA screwedness.
[05:32] <wgrant> No fish, sadly.
[05:33] <stub> slony is a computer program, not me typing furiously
[05:33] <lifeless> a small patch is a good patch
[05:34] <wgrant> stub: Anyway, do you know why the staging update exploded yesterday?
[05:34] <stub> (Replication lag is spiking. Make stub another coffee!)
[05:34] <wgrant> Some slony error.
[05:34] <wgrant> That is not entirely obvious.
[05:34] <wgrant> stub: Ahh, I noticed there was multi-minute lag on some stuff an hour ago.
[05:35] <stub> the slony error will be that it obfuscates the real error most likely
[05:35] <wgrant> The forwarded email didn't look like the usual patching failure.
[05:36] <wgrant> 2011-02-23 07:35:19 INFO    Waiting for cluster to sync.
[05:36] <wgrant> /tmp/slonik5hZrbc.sk:27: timeout exceeded while waiting for event confirmation
[05:36] <wgrant> 2011-02-23 07:45:20 ERROR   slonik script failed
[05:36] <wgrant> Not a patching issue :/
[05:36] <stub> Yup
[05:36] <wgrant> Hmm, one long transaction.
[05:36] <wgrant> Except it wasn't long.
[05:36] <stub> Its sad when I consider an automated system that works most of the time a successful improvement
[05:36] <wgrant> Ahh, pofilestats was running.
[05:36] <wgrant> That could do it.
[05:37] <wgrant> It probably still is.
[05:37] <wgrant> That's quite a serious transaction it has there.
[05:37] <wgrant> Are qastaging and staging in the same replication thingy?
[05:38] <StevenK> soren: Do you know what plugins the OpenStack Hudson is using? I'm interested in the merging one that posted to the MP
[05:39] <lifeless> mtaylor: ^
[05:40] <lifeless> wgrant: no
[05:40] <lifeless> wgrant: qas has no replica
[05:40] <lifeless> wgrant: staging has one replica
[05:40] <StevenK> Then we can replace both PQM and BuildBot with Jenkins!
[05:40] <wgrant> StevenK: Once we unbreak windmill.
[05:40] <wgrant> Which could be approximately infinitely far in the future.
[05:40] <StevenK> Windmill makes me sad.
[05:41] <wgrant> It also doesn't work at all with Firefox 4.
[05:52] <wgrant> StevenK:
[05:52] <wgrant> Test-module import failures:
[05:52] <wgrant> Module: lp.scripts.tests.test_sphinxdocs
[05:52] <wgrant> TypeError: Module lp.scripts.tests.test_sphinxdocs does not define any tests
[05:52] <wgrant> Is that going to break anything?
[05:53] <StevenK> Oh, DAMN IT
[05:54] <StevenK> TestCase, I hate you
[05:54] <StevenK> Yes, it is
[05:54] <wgrant> That's a little stupid.
[05:56] <lifeless> \o/
[05:56] <lifeless> stub: just organising dinner; call after?
[05:57] <stub> Sure.
[05:57] <wgrant> Hmmm.
[05:57] <wgrant> I want to increment this rollout request.
[05:57] <stub> Caffeinated. Still stuck with silly sleep cycle though.
[05:58] <lifeless> wgrant: do so
[05:58] <wgrant> lifeless: But that will make jml and Ursinha sad :P
[05:58] <lifeless> wgrant: it was a learning exercise for Ursinha - and she has learnt
[05:58] <lifeless> wgrant: I would increment yours, if you were asleep and more was ready
[05:58] <lifeless> just put Ursula, william as the requestors
[06:00] <wgrant> Hopefully we can do two tonight.
[06:01] <wgrant> Since there are 9 revs stuck in buildbot.
[06:01]  * StevenK waits for bzr
[06:02]  * wgrant cuts off shipit's fingers as they go near anywhere except lp.shipit
[06:02] <StevenK> Oh?
[06:03] <wgrant> Removing the canonical.widgets imports, mainly.
[06:04]  * StevenK cheats
[06:04] <wgrant> That's cheating.
[06:05] <StevenK> Uh, wgrant, I think the import facist hates you
[06:05] <StevenK> ** 1 import policy violations **
[06:05] <StevenK> There were 1 imports of names not appearing in the __all__.
[06:05] <StevenK> You should not import UnknownRemoteValueError from lp.bugs.externalbugtracker:
[06:05] <wgrant> It does, yes.
[06:05] <StevenK>     lp.bugs.scripts.checkwatches.remotebugupdater
[06:05] <wgrant> I noticed that earlier and was going to slip a fix into my query counts branch.
[06:05] <mtaylor> StevenK: aroo?
[06:05] <StevenK> mtaylor: O hai
[06:05] <mtaylor> hey - so, we're just having hudson trigger tarmac
[06:06] <mtaylor> I _REALLY_ want to finish some work on plugins for jenkins to allow it to not need tarmac but instead directly interface with launchpad
[06:06] <mtaylor> but that stalls every time I try to make progress onit
[06:06] <StevenK> mtaylor: How? I was strugging to figure out how to get Jenkins to do anything after a build finished
[06:07] <StevenK> wgrant: I can't test this cheat with that import error :-(
[06:07] <mtaylor> StevenK: there are post-build triggers
[06:07] <wgrant> StevenK: Hm? That's not an error...
[06:08] <lifeless> \o/ working
[06:08] <lifeless> stub: skype?
[06:08] <StevenK> mtaylor: I see them, but there doesn't seem to be a "Go and run this script for me" one
[06:09] <mtaylor> StevenK: I _think_ you can do that, but I don't do that so I don't know
[06:09] <StevenK> mtaylor: Also, does that mean you have Jenkins testing random branches?
[06:10] <lifeless> StevenK: thats easy; parameterised :)
[06:10] <StevenK> wgrant: http://pastebin.ubuntu.com/571547/
[06:10] <wgrant> StevenK: Success.
[06:10] <mtaylor> StevenK: I do have jenkins set up with parameterized builders both for drizzle and openstack
[06:11] <mtaylor> StevenK: although the openstack one is less useful since we're just using jenkins to trigger tarmac for openstack. for drizzle, the param-build jobs are essential and excellent
[06:11] <mtaylor> lifeless: have I mentioned how sad I am that I havne't gotten those jenkins plugins done yet?
[06:12] <wgrant> production deployments don't respect the revisions in sourcedeps.conf, do they?
[06:16] <lifeless> mtaylor: you have
[06:18] <StevenK> wgrant: My cheating makes me sad: http://pastebin.ubuntu.com/571557/
[06:19] <wgrant> StevenK: Can't you just rename the file?
[06:20] <StevenK> oh, disabled_test_... ?
[06:20] <wgrant> .py.goaway
[06:20] <wgrant> Or maybe disabled_test...
[06:20] <wgrant> Not sure if that works.
[06:20] <wgrant> Preferably the prefix.
[06:20] <lifeless> uhm
[06:21] <lifeless> prefix preferred for sure
[06:22] <wgrant> For doctests we suffix.
[06:23] <StevenK> Fix pushed into PQM
[06:28] <StevenK> It would be nice if the deployment report also said how far behind qas is, which might hint at a buildbot stall or os
[06:28] <StevenK> s/os$/so/
[06:28] <StevenK> Er, how far behind stable tip qas is
[06:30] <wgrant> I'd really like the report to list all revisions in devel, split into what is on qas, what is waiting for deploy to qas, what is in buildbot, what is waiting for buildbot.
[06:30] <wgrant> And somewhere listing in-progress ec2 runs would be handy.
[06:31] <lifeless> lp:~lifeless/launchpad/profile
[06:31] <lifeless> pushing now
[06:31] <StevenK> wgrant: In-progress ec2 runs is *hard*
[06:41] <lifeless> stub: https://code.launchpad.net/~lifeless/lp-production-configs/single-threaded/+merge/41554 has a script to add configs
[06:44] <lifeless> stub: https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout
[06:47] <lifeless> stub: if you wanted to review https://code.launchpad.net/~lifeless/launchpad/profile/+merge/51078 that might be nice
[06:47]  * lifeless goes eats
[06:48] <wgrant> Interesting.
[06:48] <wgrant> I can set the importance of ShipIt bugs, but can't mark them Triaged.
[06:57] <lifeless> backs
[06:57] <lifeless> nomification vacuumed
[06:57] <wgrant> Excellent.
[06:59] <lifeless> stub: hey; the staging and qastaging restores
[06:59] <lifeless> stub: can they inject a feature flag ?
[07:00] <wgrant> Can't we add a server:qastaging?
[07:00] <lifeless> wgrant: still wouldn't want that on production
[07:00] <lifeless> in event of a mishap it would be bad
[07:00] <stub> Sure. Its just a shell script. It could also be injected in database/replication/Makefile but for a hack just for staging the shell script is a better fit.
[07:00] <lifeless> wgrant: oh, and scopes have no boolean operators
[07:01] <lifeless> wgrant: so it wouldn't help.
[07:02] <lifeless> stub: I'd like to get 'profiling.enabled team:launchpad 0 on' added when the staging and qastaging systems come online
[07:02] <stub> lp:~canonical-losas/lp-staging-scripts/trunk is where the staging restore script lives
[07:02] <lifeless> stub: we also should add those to the current databases
[07:02] <stub> Do you want these flags added via config file items, or just hard coded in the rebuild scripts?
[07:03] <stub> scrap that... config file items would need to handle removal too and becomes a much bigger problem...
[07:03] <lifeless> stub: exactly, just added in the rebuilt scripts
[07:03] <lifeless> and manually nowish to the existing [qa]staging servers
[07:06] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/everything-into-lp.shipit/+merge/51080
[07:09] <wgrant> Thanks.
[07:19] <stub> We have a nice web ui for adding feature flags to live systems somewhere...
[07:20] <wgrant> stub: /+feature-rules?
[07:22] <stub> This script is a piece of poo
[07:33] <wgrant> Wiiiiindmiiiiiiiiiiiiiiil
[07:39] <stub> lifeless: https://code.launchpad.net/~stub/lp-staging-scripts/devel/+merge/51082
[07:42] <lifeless> stub: will that affect qastaging as well?
[07:48] <LPCIBot> Project devel build (470): STILL FAILING in 4 hr 49 min: https://hudson.wedontsleep.org/job/devel/470/
[07:48] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless, wgrant][ui=sinzui][bug=712773, 722344] Show which recipe,
[07:48] <LPCIBot> its build and the requester are responsible for the creation of the
[07:48] <LPCIBot> publishing record in the detail of a PPA's +packages page.
[07:48] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=724013] Actually eager load message owners in
[07:48] <LPCIBot> Bug._indexed_messages.
[07:48] <LPCIBot> * Launchpad Patch Queue Manager: [r=stub][bug=722429] Eager load milestones used in bug search result
[07:48] <LPCIBot> tables.
[07:48] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=592345,
[07:48] <LPCIBot> 719288][incr] Several checkwatches OOPSes have been demoted to INFO
[07:48] <LPCIBot> log entries.
[07:52] <lifeless> stub: I've lowered the oauthnonce thing to low given its not making trouble at the moment; feel free to make it high or $whatever if I've assessed it wrongly
[08:08] <soren> StevenK: That would be Tarmac.
[08:13] <stub> lifeless: thats fine
[08:13] <stub> lifeless: No. I'm not sure where the qastaging rebuild scripts live.
[08:13] <wgrant> Is there a qastaging rebuild script?
[08:13] <lifeless> there is a means
[08:13] <lifeless> I don't know the rest
[08:16] <lifeless> stub: could I beg a review from you - https://code.launchpad.net/~lifeless/launchpad/profile/+merge/51078
[08:22] <lifeless> stub: I forgot to highlight https://dev.launchpad.net/LEP/OopsDisplay for a once over
[08:23] <stub> k
[08:32] <stub> lifeless: reviewed
[08:34] <lifeless> thanks
[08:39] <stub> lifeless: nice to have: short OOPS codes. If you are going for md5 for oops id, might as well just use uuid
[08:39]  * stub tries to recall how well an md5 can be compressed
[08:39] <lifeless> stub: uuids are ~ the same length
[08:40] <lifeless> stub: we could just use the first N bits of (any) hash and be (probably) unique
[08:40] <lifeless> e.g. if we're doing 6M in a month
[08:40] <lifeless> and gcing at 30 days
[08:41] <lifeless> then taking, oh, 40 bits, would be pretty unlikely to collide within the lifespan of the oops
[08:41]  * stub wonders where his base.py disappeared too
[08:41] <lifeless> it belongs to us
[08:41] <lifeless> you are right though, uuids would also do the job, using libuuid or whathave you
[08:42] <lifeless> (40 bits is 10 characters in hex - 0123456789
[08:42] <lifeless> which is pretty short
[08:43] <stub> lp.services.utils.compress_hash shrinks an md5 to 22 ascii characters (converts the number to base62)
[08:43] <lifeless> cool
[08:44] <stub> I guess that is fine given our oops prefixes are getting looong already
[08:44] <lifeless> is that available outside the lp tree?
[08:44] <stub> not yet, but it probably should since the base() function it uses is PSF licence and pulled from the Python Cookbook.
[08:45] <lifeless> I want to write oops-repository as a lightweight project not needing the lp tree, so that other teams can deploy it sanely
[08:45] <stub> yup
[08:46] <mrevell> Hello
[08:47] <stub> I suspect local rabbits on each server is overkill. I think we don't care about occasional lost OOPSes enough to warrent the extra complexity.
[08:48] <lifeless> stub: I'm torn
[08:49] <lifeless> on one hand, it is slightly more setup (only slightly - rabbit, durable queue, shovel - done.)
[08:49] <stub> But then we have three moving parts to fail rather than one.
[08:50] <lifeless> but less dependencies
[08:51] <lifeless> if we do just one rabbit, we have more complex code
[08:52] <lifeless> the appserver code would have more reason to be tolerant of that rabbit being down for maintenance (whereas with a federation we can just bring the local rabbit up before the appserver)
[08:52] <lifeless> anyway, it won't change the code we write
[08:52] <lifeless> the contract is 'speak to a rabbit' on both ends
[08:52] <lifeless> as long as we can configure the rabbbit node to use, its flexible enough to run in either config without change
[08:53] <stub> I'm used to more moving parts increasing downtime
[08:53] <stub> Too many systems attempt to reduce downtime by creating redundancy and end up increasing it because there are more things that can screw up.
[08:54] <lifeless> thats certainly possible!
[08:54] <lifeless> we can afford to lose some oopses
[08:54] <lifeless> I'd hesitate to lose hours though, in the event of (say) devpad failing
[08:57] <stub> Of course, if casandra is distributed and never goes down we could have the appservers stuff OOPSes directly in there.
[08:58] <lifeless> we could
[08:58] <lifeless> I'm totally open to that as well
[08:59] <lifeless> one advantage for u1 of rabbit is that they have a lot of network glitches, which cassandra wouldn't help with
[08:59] <wgrant> Is that because they are partly on EC2?
[09:00] <lifeless> entirely because of that
[09:00] <stub> if we want short OOPS ids, systems could pull unique integers from rabbit (fed from some source maintaining the central counter)
[09:00] <lifeless> stub: I don't particularly care about short OOPS ids - and having a central allocator would force an api-call rather than a fire and forget model
[09:05] <lifeless> what would short oops ids help us with ?
[09:09] <stub> lifeless: Making them citable. bug reports, irc conversations, even phone calls.
[09:10] <lifeless> all but phone calls are copy and pastable
[09:11] <stub> a script or appserver could pull a unique prefix and then use it to generate unique ids
[09:11] <lifeless> for phone calls, once they are in the database, we can use the prefix logic git and hg do to let you cite just a unique prefix
[09:11] <stub> They are copy and pastable, but not readable
[09:13] <stub> Bug reports with 'See OOPS-X542327' vs. 'See OOPS-ACBD18DB4CC2F85CEDEF654FCCC4A4D8'
[09:13] <stub> Much more space chewed up, much less readable == sucky ui
[09:14] <lifeless> mmm
[09:14] <lifeless> I see the point, but it doesn't feel very compelling
[09:15] <lifeless> I am possibly overreacting to the current headaches
[09:16] <stub> manually allocated prefixes suck cause people mess up (even if they are slightly nicer in that you can use them to identify the system the OOPS came from without looking at the content). But long ids suck too because of the sheer volume we are constantly wading through.
[09:27] <lifeless> OOPS-68b329da9893e34099c7d8ad5cb9c940 - thats an actual md5sum
[09:27] <lifeless> OOPS-1202CBB1234
[09:27] <lifeless> thats our current oopses
[09:27] <lifeless> so its about twice as long
[09:28] <bigjools> nicely rounded down :)
[09:29] <lifeless> OOPS-1202CBB1234OOPS-1202CBB1234
[09:29] <lifeless> OOPS-68b329da9893e34099c7d8ad5cb9c940
[09:37] <stub> 6 digit bug numbers suck too. Should have made the ids alphanumeric :)
[09:45] <jtv> mwhudson: you still here by any chance?  Got a problem with the ec2 image, and heard you might know.
[09:53] <jtv> WTF?  WTF?  WTFF?
[09:54] <jtv> bigjools: /etc/apt/sources.liste
[09:54] <jtv> sic
[09:54] <bigjools> jtv: that pulsing  vein is getting bigger
[09:54] <jtv> They are identical though
[09:54] <bigjools> that sounds suboptimal
[09:55] <jtv> But shouldn't there be a sources.list[.d] entry for the Launchpad PPA?
[09:55] <bigjools> yes
[09:55] <bigjools> I think
[09:58] <bigjools> stub: if we add a ulimit on memory for the librarian, how big should it be?
[09:59] <stub> Dunno. Guestimate by losa?
[09:59] <bigjools> ok
[09:59] <stub> If we spool uploads and/or downloads into RAM, fucking huge (and a bug report opened)
[09:59] <mthaddon> stub: enough so that it's not using swap I guess
[10:00] <bigjools> well it was at 15GB when it went awol
[10:00] <stub> mthaddon: Sounds sane
[10:01] <mthaddon> bigjools: we have mizuho configured with a ton of swap as when we didn't the process was dying before we could debug it, but that doesn't mean we *want* it to be using that much
[10:01] <bigjools> indeed
[10:01] <stub> It *should* be small, even with a dozen threads and handling large files.
[10:03] <bigjools> I'm filing an RT to get a ulimit
[10:04] <mthaddon> bigjools: you realise this is just going to mean the librarian process crashes when it hits the ulimit rather than crashing later?
[10:04] <bigjools> mthaddon: yes - I am just doing what I've been asked to do :)
[10:04]  * mthaddon nods
[10:05] <bigjools> mthaddon: I don't think it crashed before BTW, it just went very slow
[10:05] <bigjools> it's preferable to have it crash so you get an alert
[10:06] <mthaddon> the problem we had before was it crashed before we could get debug info, which is why we changed it - it sounds like setting ulimit is going to mean it goes back to crashing before we can do any debugging
[10:06] <bigjools> ok, you might want to put that on the RT
[10:09] <mthaddon> k
[11:21] <bigjools> jml: man I am so jealous of the twisted test suite:  real    1m44.882s
[11:24] <jml> bigjools: yeah. I was going to reply to your comment about the Twisted landing process.
[11:24] <bigjools> it was somewhat tongue in cheek :)
[11:24] <jml> bigjools: even though Twisted has stricter standards than Launchpad in many ways, it's still way easier to land stuff.
[11:37] <bigjools> jml: they need to start using bzr/lp for hosting the code - using svn again was kinda painful!
[11:37] <jml> bigjools: tell me about it.
[11:37] <bigjools> I didn't realise how much I relied on local committing
[11:37] <jml> or shelve, or revert working, etc.
[11:42] <adeuring> allenap: do you have time for a review? https://code.launchpad.net/~adeuring/launchpad/bug-688130/+merge/51107
[11:43] <allenap> adeuring: Sure.
[11:43] <adeuring> allenap: thanks!
[11:48] <bigjools> it pains me that poppy, which was one of the last truly free scripts, now has to load the zcml
[11:51] <wgrant> gina :D
[11:52] <wgrant> Or does that load ZCML, but just completely ignore its existence?
[11:52] <bigjools> it uses getUtility, so no
[11:53] <bigjools> poppy-sftp will be doing that also, so I had to call execute_zcml_for_scripts
[12:03] <jml> bigjools: codehosting held out for a while.
[12:04] <deryck> Morning, all.
[12:06] <bigjools> jml: resistance is futile ...
[12:10] <wgrant> deryck: Morning.
[12:22] <jtv-afk> Could someone try an "ec2 land" to see if it works now?
[12:23] <wgrant> jtv-afk: What have you changed?
[12:23] <jtv-afk> Generated new image, from newer lucid
[12:23] <wgrant> It will still have the new bzr.
[12:23] <wgrant> 'import bzrlib.plugins.pqm' needs to work in a fresh python
[12:23] <wgrant> Or we need to patch ec2test-remote.py
[12:45] <jml> Has this error been fixed:
[12:45] <jml> You should not import UnknownRemoteValueError from lp.bugs.externalbugtracker:
[12:45] <jml>     lp.bugs.scripts.checkwatches.remotebugupdater
[12:46] <wgrant> jml: It's in an MP of mine.
[12:46] <wgrant> https://code.launchpad.net/~wgrant/launchpad/secret-query-count-determinism/+merge/51086
[12:48] <StevenK> wgrant: Can you also revert that 42 to 43 business in that branch?
[12:48] <jml> wgrant: approve w/ tweak.
[12:59] <wgrant> StevenK: I can't, sadly.
[12:59] <wgrant> StevenK: That bump was legit.
[12:59] <wgrant> StevenK: There is actually one more query now.
[12:59] <wgrant> You added one when you changed PPA traversal.
[12:59] <wgrant> So the failure in ec2 was not spurious, but the local failure was.
[13:00] <StevenK> Ah
[13:00] <wgrant> Same test, same failure, different cause.
[13:00] <StevenK> Heh
[13:00] <wgrant> (yes, that took a while to work out)
[13:06] <elmo> so - I'm confused, am I blind or is +copy-packages really a hidden URL?
[13:06] <wgrant> elmo: For the primary archive it is deliberately unlinked.
[13:06] <wgrant> For PPAs you need to "View package details" first.
[13:06] <elmo> also - how does the 'rebuild the copied sources' option work when you're copying within the same PPA?  is it a binonlyNMU style thing?
[13:06] <wgrant> elmo: It doesn't.
[13:06] <wgrant> It will refuse to rebuild into the same archive.
[13:07] <elmo> ok
[13:07] <elmo> bother
[13:07] <wgrant> Roughly, yes.
[13:07] <elmo> also, is there anyway to transition a PPA from one person to a group?  or should I just copy all the packages (including binaries) from one ppa to the other and then delete the original?
[13:08] <wgrant> You cannot reassign a PPA. Your suggested method is the best workaround.
[13:08] <bigjools> the latter
[13:08] <elmo> cool - thanks guys
[13:13] <LPCIBot> Project devel build (471): STILL FAILING in 5 hr 25 min: https://hudson.wedontsleep.org/job/devel/471/
[13:13] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=724138][incr] Add remaining shipit canonical.*
[13:13] <LPCIBot> imports to lp.shipit.
[13:13] <LPCIBot> * Launchpad Patch Queue Manager: [rs=stevenk][no-qa] Unbreak the testsuite,
[13:13] <LPCIBot> disable the entire test_sphinxdocs file.
[13:13] <LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless,
[13:14] <LPCIBot> stevenk][bug=706992][no-qa] Fix the spurious LibrarianWebTestCase
[13:14] <LPCIBot> test failures by restricting LFA ID replacement to the path.
[13:14] <LPCIBot> * Launchpad Patch Queue Manager: [rs=stevenk,
[13:14] <LPCIBot> wgrant][no-qa] Disable the Sphinx docs test due to spurious failures.
[13:15] <leonardr> geser: while we wait for benjamin (stephano is away), i'll summarize
[13:15] <jml> I didn't see a bug filed about that last one.
[13:15] <leonardr> in previous versions of launchpadlib, you had to get a separate credential for every application, and the credentials were stored unencrypted on disk
[13:15] <jml> oh well. I guess I know now.
[13:16] <wgrant> jml: It was the _LockWarner one.
[13:16] <wgrant> jml: The Sphinx test just breaks on it more often than the rest.
[13:16] <leonardr> geser: now the user gets a single credential that authorizes every application they run on their computer, and the single credential is stored in the gnome keyring or kde waller (with a fallback to an encrypted file on disk if neither is running)
[13:16] <wgrant> jml: Three builds in a row got it, plus one on Hudson, so we decided to kill it.
[13:17] <bdrung> leonardr: hi
[13:17] <jml> wgrant: fair enough. thanks.
[13:17] <leonardr> bdrung: hi, let me re-paste what i just told geser
[13:17] <leonardr> in previous versions of launchpadlib, you had to get a separate credential for every application, and the credentials were stored unencrypted on disk
[13:17] <geser> leonardr: ah that change, I've read about it
[13:17] <leonardr> now the user gets a single credential that authorizes every application they run on their computer, and the single credential is stored in the gnome keyring or kde waller (with a fallback to an encrypted file on disk if neither is running)
[13:18] <leonardr> in ubuntu-dev-tools there's some code (find_credentials) to look for a credential file on disk
[13:19] <leonardr> there's also some code to automatically approve an oauth request token, which 1) is something we're trying to get rid of, and 2) will only work for users who got their launchpad accounts before we started using the openid login service
[13:19] <wgrant> jml: Can I get a rereview of that branch in a sec? I was going to fix ec2 land in another branch, but since it's trivial and I can't land this one without it...
[13:19] <jml> wgrant: sure, np.
[13:20] <leonardr> there's also some minor cleanup: you use a method get_token_and_login which has been deprecated
[13:20] <geser> leonardr: does the new launchpadlib auth method also work in Debian without problems? (server installs or people not using KDE or gnome)
[13:21] <leonardr> and in the documentation, and in at least one place in the code, you assume that the server is either 'staging' or 'edge'. there are many more choices now, and 'edge' no longer exists
[13:21] <leonardr> geser: if you're not using kde or gnome, the keyring library stores the keys in an encrypted file on disk. it's not ideal, but it seems to work
[13:22] <leonardr> the keyring system does not work for scripts that must run unattended (such as cron scripts)
[13:22] <wgrant> jml: Diff updated.
[13:23] <leonardr> for those you still must get a credential, write it unencrypted to a file, and pass the filename into Launchpad.login_with()
[13:25] <leonardr> hi, tumbleweed
[13:25] <tumbleweed> leonardr: hi, yes this has been on my todolist for a while
[13:25] <leonardr> tumbleweed: i just summarized the changes i think need to be made. let me pastebin the conversation to avoid repeating it in this channel
[13:25] <jml> wgrant: just thinking if there's a sensible way to test the plugin change.
[13:25] <leonardr> http://pastebin.ubuntu.com/571711/
[13:25] <wgrant> jml: I don't think that can really be tested. Apart from by landing it.
[13:26]  * leonardr refreshing his memory of how you're supposed to get a credential for a cron script
[13:27] <leonardr> good. you just run your code, and if the credential file doesn't exist, you get a browser open, and the credentials are written to that file.
[13:27] <jml> wgrant: ok. approved w/ comments.
[13:28] <wgrant> jml: It needs to be run in a subprocess in the right Python environment :/
[13:28] <wgrant> jml: On vanilla Lucid it works fine without it.
[13:28] <jml> wgrant: oh yuck.
[13:28] <wgrant> It's the new bzr PPA packaging that killed things.
[13:29] <leonardr> tumbleweed, geser, bdrung: i've blocked out my whole day for talking to developers. once i locate everybody i need to locate, i can sketch out some code changes for u-d-t if you like
[13:29] <leonardr> do you have any questions about these changes?
[13:30] <tumbleweed> leonardr: sorry I've just sat down at my desk, and people are coming at me left, right and centre
[13:30] <tumbleweed> and now the power has failed
[13:30] <leonardr> tumbleweed: np, like i said, i'm here all day
[13:30] <jml> wgrant: today, it's slightly harder to believe that software can make the world a better place.
[13:30] <tumbleweed> but I followed the LP bug about the previous upgrade, so I know vaguely what's happeneing
[13:30] <tumbleweed> for u-d-t it should be quite simple, because the login code is centralised in acouple of places
[13:31] <wgrant> jml: Yes.
[13:31] <wgrant> But on the other hand I tracked down the librarian spurious failures.
[13:31] <wgrant> And that makes me very happy.
[13:32] <jml> wgrant: yeah, I saw that last night and was very happy. Well done.
[13:32] <leonardr> tumbleweed: one more thing i noticed (i may just say these random things)
[13:33] <leonardr> translate_api_web is no longer necessary, since all web service objects that are also published on the website have a web_link. you could add a deprecation warning
[13:33] <geser> leonardr: does u-d-t just simply use Launchpad.login_with(...) and launchpadlib will take care of everything or do we need some additional handling code?
[13:33] <jml> I'm going to go outside for lunch & errands and to enjoy the blue sky.
[13:33] <jml> back soon.
[13:34] <leonardr> geser: the goal is that you use login_with and launchpad will take care of everything
[13:34] <leonardr> but i don't know what the people who use your library are expecting
[13:34] <geser> leonardr: we use already web_link where possible, only one place left (manage-credentials) but it looks like we can dump that script completely soon
[13:34] <leonardr> wow, that caught on quickly
[13:35] <bdrung> leonardr: translate_api_web is only used in manage-credentials
[13:35] <leonardr> oh, it's not even translating a self link. i see
[13:35] <leonardr> i thought it was a service you provided your users to work around the lack of web_link
[13:38] <jml> wgrant: I also saw your shipit change. Thanks for that.
[13:38] <jml> wgrant: are you planning on patching shipit to only import from lp.shipit?
[13:38] <wgrant> jml: It's part 1 of 3.
[13:38] <bdrung> leonardr: to summarise: the script just have to use login_with and don't care about the credentials?
[13:38] <wgrant> jml: Yes, the branch is up.
[13:38] <wgrant> But I dare not land it until this is deployed.
[13:38] <jml> wgrant: cool. makes sense. I think I can guess what part 3 is.
[13:40] <jml> really off now.
[13:41] <bdrung> leonardr: with version of launchpadlib is required for playing with the new code?
[13:41] <tumbleweed> leonardr: ok, things have calmed down a bit. I was hoping we'd be able to get rid of manage-credentials (which is why it still has edge somewhere), but I guess we'll need it for non-interactive u-d-t use
[13:42] <tumbleweed> bdrung, leonardr: and is this available packaged somewhere?
[13:42] <leonardr> bdrung: i recommend 1.9.3, the latest version. it makes get_token_and_login work with a deprecation warning (in previous versions it was just broken)
[13:42] <leonardr> tumbleweed: it's in natty
[13:42] <geser> leonardr: translate_api_web was used that way before web_link appeared, but we switched to web_link soon after an entry about it appeared on planet
[13:42] <leonardr> barry also has it in a ppa
[13:42] <leonardr> but i was never able to get his ppa version to work because of a problem with his package of python-keyring
[13:42] <tumbleweed> yeah I think translate_api_web is only used in manage-credentials now
[13:42] <geser> tumbleweed: which non-interactive scripts are in u-d-t?
[13:43] <tumbleweed> we still have translate_web_api, though
[13:43] <leonardr> tumbleweed: i think you can get rid of manage-credentials altogether. i don't see any difference between calling manage-credentials and calling login_with() and passing in a credential file
[13:43] <tumbleweed> geser: nothing I can think of
[13:45] <wgrant> jtv: Hi.
[13:45] <jtv> hi
[13:45] <jtv> just looking into what you said
[13:46] <wgrant> jtv: Fix already in ec2.
[13:46] <tumbleweed> geser: although, what about using these scripts on a remote box over ssh, I do that quite a lot...
[13:46] <jtv> !
[13:46] <wgrant> Since I needed to land a branch :P
[13:46] <jtv> wgrant: that's fantastic, thanks!
[13:46] <wgrant> jtv: Is your rev likely to be QA'd today?
[13:46] <jtv> wgrant: which rev?
[13:46] <wgrant> jtv: pofilestats perms.
[13:47] <wgrant> It is the sole thing between us and complete deployment.
[13:47] <geser> tumbleweed: better ask leonardr, I don't know who that works in this case
[13:47] <jtv> Then I'll do that.  So many urgent things going on…
[13:48] <leonardr> tumbleweed: you'll need to set something up to get gnome-keyring running over the x session. it's pretty easy, let me find it
[13:48] <wgrant> jtv: That would be great. If I'm still around I'll request the deploy, but if not then it'd be great if someone else could.
[13:48] <wgrant> Thanks.
[13:48] <jtv> I'll expedite it.
[13:48] <Ursinha> I can
[13:48] <jtv> Ursinha: it's blocked on my Q/A
[13:48] <jtv> which I'm doing right now
[13:49] <Ursinha> right :)
[13:49] <tumbleweed> leonardr: that doesn't sound like it'd play well with screen
[13:49] <geser> leonardr: I'm using a natty chroot (with bind-mounted /home and /tmp) for development (to not pollute my main system with -dev packages and to be able to upgrade it earlier on the next development release). Will it continue to work in such an environment?
[13:50] <tumbleweed> leonardr: will it fall back to an on-disk credential? And would there be an easy way to create such a credential, included in launchpadlib / lptools?
[13:50] <leonardr> geser: tumbleweed: i don't know. try it. if there's going to be a problem, better to find out now
[13:51] <leonardr> if it can't access a keyring it should use an encrypted file on disk
[13:51] <leonardr> but there might be a problem if the keyring is there but communication with it is impossible
[13:51] <tumbleweed> yeah I remember issues like that with bzr gtk
[14:01] <leonardr> tumbleweed: fwiw, the workaround is to put "export `gnome-keyring-daemon`" in your .bashrc
[14:01] <leonardr> and that's useful in general
[14:09] <bdrung> leonardr: can sketch out some code changes in a separate branch?
[14:10] <leonardr> bdrung: i can, but it'll need to wait until i contact the rest of the develoeprs
[14:10] <bdrung> leonardr: why do you have to wait?
[14:11] <leonardr> bdrung: sorry, are you asking me to sketch out the code changes, or are you saying you'll do it?
[14:11] <bdrung> leonardr: bug #724327
[14:11] <bdrung> leonardr: i was asking you
[14:12] <leonardr> bdrung: that bug is private
[14:12] <leonardr> my priority is making sure everyone knows about this change
[14:13] <bdrung> leonardr: public now
[14:14] <leonardr> bdrung: did you install from the ppa? python-keyring should now be a dependency of python-launchpadlib
[14:15] <bdrung> leonardr: the official package in natty
[14:15] <leonardr> bdrung: ok, sounds like a dependency problem. try installing python-keyring and see if that helps
[14:18] <bdrung> leonardr: it works then
[14:18] <leonardr> bdrung: ok, i'll turn the bug into a launchpadlib-in-ubuntu bug
[14:21] <tumbleweed> leonardr: OOPS-1881A1326
[14:21] <tumbleweed> seems to have authed, though
[14:21] <leonardr> i can't see the oops yet, but i bet i know what it is
[14:21] <bigjools> jml: do our test fixtures give any way of having a fixture that hang around longer than one test?  I've got a slow setup phase running up a  KeyServerTac  process that doesn't really need to go up and down
[14:22] <leonardr> tumbleweed: can you paste me the exception so i can find the bug?
[14:23] <tumbleweed> leonardr: there was no exception, I got that after confirming the oauth in my browser
[14:23] <tumbleweed> on a +token-authorized page
[14:23] <leonardr> tumbleweed: it's bug 271010
[14:23] <_mup_> Bug #271010: OOPS accessing a non-existent oauth token page. <api> <lp-foundations> <oauth> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/271010 >
[14:24] <leonardr> we can fix it on the server side
[14:24] <gary_poster> allenap hi.  I just saw your reply to bug 723999.  Thank you!  Do I correctly understand your reply to say that, to the best of your knowledge, the query is doing the right/expected thing right now?  Moreover, do I also understand correctly that you do not see a way to improve it (at this time) without offlining the recipient calculation, as discussed at the end?
[14:24] <_mup_> Bug #723999: structural subscriptions taking 4.8 seconds during nomination editing POST <story-better-bug-notification> <timeout> <Launchpad itself:Triaged by yellow> < https://launchpad.net/bugs/723999 >
[14:24] <jml> bigjools: not yet.
[14:25] <bigjools> jml: ok I'll file a bug, which would be the right project, testtools?
[14:25] <jml> bigjools: it's a good enough place to start.
[14:25] <bigjools> ok cheers
[14:25] <allenap> gary_poster: Yes, on both counts.
[14:26] <gary_poster> allenap, ok, thank you again.
[14:26] <jml> bigjools: a cheap fix might be to write a fixture -> layer adapter.
[14:26] <tumbleweed> bdrung, geser: pushing my quick porting to lp:~stefanor/ubuntu-dev-tools/launchpadlib-1.9 (but I don't have too much free time this week)
[14:26] <jml> bigjools: I would like to do it properly though (i.e. have something that could replace layers).
[14:26] <bigjools> hellyes
[14:28] <jcsackett> henninge: any chance i can get your input to answer a question on answers.lp? (per danilos suggestion of trying to get some knowledge transfer going. :-))
[14:29] <henninge> jcsackett: what's the question?
[14:29] <jcsackett> question is https://answers.launchpad.net/launchpad/+question/146556
[14:30] <jcsackett> my belief is the answer is "no, we can't support that very specific language code"
[14:30] <jcsackett> i saw the faq you wrote about supported language codes, but it mentions exceptions can be made.
[14:30] <jcsackett> my belief, henninge, is that this is not one of the exceptions lp can support. :-)
[14:32] <henninge> jcsackett: well, for one be-1959acad is probably not an ISO lang code.
[14:33] <jcsackett> yeah, it's not in any list, which is why i figured "nope" was the answer.
[14:33] <henninge> so you would have to enter it as a variant: be@1959acad
[14:33] <henninge> He is suggesting, I think, to replace "be" with the two variants but we won't do that.
[14:34] <henninge> The translator community has to decide which variant of the language to use for "be" translations.
[14:34] <henninge> that is not our call.
[14:35] <henninge> But from what he is writing it seems that they settled on be-tarask, so the other would be the exception.
[14:36] <jcsackett> henninge: ah, okay. and the use of a variant is just a community decision, right? we don't have infrastructure to enter it as a variant or anything?
[14:36] <henninge> jcsackett: you can offer him to add "be@1959acad"
[14:37] <henninge> jcsackett: we used to have a special database field for the variant but nowadays it's just part of the language code.
[14:37] <gary_poster> mrevell, thank you for the user testing report.  I'm 2/5 through reading. :-) You said you could help with the text.  I'd be happy to take advantage of that help as much as you'd like.  For instance, if you have concrete suggestions for one or all of the pages, I'd be thrilled to get them and I expect Graham would as well.  Is that what you had in mind, or some other mechanism?
[14:37] <henninge> jcsackett: The real problem is: will many people do translations in that language? Is it worth it? Maybe he should be warned about that.
[14:38] <jcsackett> henninge: cool. okay, i'll give him the info and ask if adding be@1959acad is necessary.
[14:38] <jcsackett> thanks!
[14:38] <henninge> jcsackett: welcome.
[14:40] <jtv> wgrant, Ursinha: my branch just went qa-ok
[14:41] <Ursinha> yay
[14:41] <wgrant> jtv: Thanks.
[14:41] <wgrant> Just requested the deploy.
[14:43] <jtv> wgrant: trying to find your ec2test fix… did you have a bug for it?
[14:43] <wgrant> jtv: I stole your bug for it.
[14:43] <jtv> That's fine, thanks
[14:44] <jtv> But please attach the branch there!
[14:44] <wgrant> I thought it was...
[14:44] <wgrant> ** Branch linked: lp:~wgrant/launchpad/secret-query-count-determinism
[14:46] <jtv> wgrant: the branch name doesn't sound related
[14:47] <wgrant> jtv: It isn't, but I needed to land that through ec2, so I put it in the same branch.
[14:47] <jtv> I see
[14:50] <mrevell> jml, Yeah, that's what I had in mind. I'll look at that this afternoon.
[14:50] <mrevell> sorry jml
[14:50] <mrevell> gary_poster, that was meant for you ^^^
[14:50] <jml> heh.
[14:50] <jml> np at all.
[14:50] <gary_poster> mrevell :-) awesome thank you
[15:02] <abentley> allenap or jcsackett: could you please review https://code.launchpad.net/~abentley/launchpad/translation-splitting/+merge/50949 ?
[15:05] <allenap> abentley: It's a Translations branch so I'm not going to be much more than a glorified linter. If that's what you want, I'll take it :)
[15:07] <abentley> allenap: Is it something about Translations in particular?  Because I'm always reviewing stuff outside Code.
[15:08] <allenap> abentley: I'm happy reviewing outside of Bugs, but Translations has always eluded me for some reason.
[15:08] <allenap> I can do it, but I am always left with the feeling that I didn't really get it.
[15:09] <abentley> allenap: you could try doing a kiko-style "ask a bunch of questions" review.  I've had to learn all this recently, so I might be better at explaining.
[15:11] <allenap> abentley: Hehe, yeah. I'll do the review, though I doubt I'll fire too many questions at you.
[15:11] <abentley> allenap: cool.
[15:24] <flacoste> jcsackett: congrulations on achieving reviewrhood!
[15:24] <jcsackett> flacoste: thanks! :-)
[15:26] <danilos> allenap, jcsackett: hey-hey, I've got a branch up for review, and I'd be happy to let you guys fight over it: https://code.launchpad.net/~danilo/launchpad/bug-720826-db/+merge/51146 :)
[15:26] <danilos> (am I optimistic or what?)
[15:26] <jcsackett> danilos: i'm looking at a huge javascripty branch; i'll take a look at yours after that. :-)
[15:27] <danilos> jcsackett, cheers
[15:27] <allenap> danilos: I'm doing one for Aaron right now, but I'll take a look after that unless jcsackett gets there first.
[15:27] <danilos> excellent, that's what I like to see :) thanks guys
[15:28] <jcsackett> allenap: thanks for the review on my validator migration, btw.
[15:28] <allenap> jcsackett: You're welcome.
[15:53] <jml> build is broken
[16:24] <abentley> sinzui: Did I mention that I created a new Job type for a Packaging?  Now that I'm generalizing the code for more than just merging translations, I'm thinking of moving it to Registry.
[16:25] <sinzui> abentley: that sounds good
[16:25] <abentley> sinzui: Cool.
[16:32] <jtv> henninge: I think you've fought this as well in the past… unique violations on TM.
[16:33] <henninge> jtv: Hm ... not sure I was victorious, though.
[16:33] <jtv> henninge: wanted to bounce this off you, in case I'm missing something big: _setTranslation clears the "current" flag(s) on the incumbent(s), then sets it/them on the new message.  But we're not setting an explicit flush order.
[16:33] <henninge> jtv: I don't remember that we do, no.
[16:33] <jtv> So I added some.
[16:34] <henninge> and do they help?
[16:34] <jtv> Don't know yet!  Can't think of a meaningful way to test this.
[16:48] <jtv> henninge: also came across a bit of weirdness in the "if/ifelse" that implements the "first upstream translation overrides ubuntu translation" exception… would appreciate a second opinion to confirm that as it stands, the "if" _inside_ the ifelse clause has a condition that's always true.
[16:49] <henninge> jtv: can you point me to the code, please?
[16:50] <jtv> henninge: potmsgset, about line 1040
[16:51] <henninge> ah, yes
[16:53] <henninge> jtv: yes, it looks like that condition can go away.
[16:53] <jtv> cool, thanks
[16:54] <bigjools> why why why is bzrlib's ftp transport uploading files with a different name to the local one and then renaming it
[16:58] <allenap> bigjools: So it can detect half-uploaded files in case of a network failure, and so it can atomically replace existing files (again, protecting against network failure)?
[16:58] <bigjools> allenap: all very nice but it totally fucks up my tests
[16:59] <bigjools> not to mention the server-side upload checks
[16:59] <allenap> bigjools: I was about to ask if that was the bother.
[16:59] <bigjools> oh well I will use ftplib instead of bzrlib
[17:00] <jtv> jcsackett: congrats on becoming a reviewer!  Want to exercise your new power?
[17:00] <jcsackett> jtv: sure, especially if it's the branch to deal with that weird translation issue. :-)
[17:00] <jtv> jcsackett: ah! :)  This one?  https://code.launchpad.net/~jtv/launchpad/bug-708385/+merge/51169
[17:00] <jcsackett> jtv: indeed.
[17:01] <allenap> sinzui: I have a branch to allow async merging of people and teams. It's not wired into any of the existing call-sites yet. I wonder if you have a few minutes to discuss the best way to do that?
[17:01] <allenap> sinzui: https://code.launchpad.net/~allenap/launchpad/async-person-merge-162510/+merge/50919
[17:01] <jtv> jcsackett: I got the branch, you got the skillz, let's do this thing
[17:01] <jcsackett> jtv: i'm looking now. :-)
[17:02] <jcsackett> danilos: r=me, but there's a not about a test doc string you should change. :-)
[17:05] <jcsackett> jtv: that was the smallest most straightforward branch i've seen today.
[17:05] <jcsackett> r=me, no comments. thanks for dealing with that.
[17:05] <jtv> jcsackett: thanks!
[17:07] <jml> sinzui: I actually quite like the way the Light font looks on Launchpad.
[17:07] <sinzui> allenap: this is great. I think you mean you want delete team, merge, team merge admin merge to show a message that this job is in progress. delete team and merge are most crucial because they are used by users
[17:08] <danilos> jcsackett, great, thanks
[17:09] <sinzui> jml: I agree. official font-size appear a little smaller in my browser and screen size. Light also has narrower headings.
[17:09] <bigjools> I borked buildbot
[17:09] <bigjools> no idea how
[17:10] <allenap> sinzui: Yes, something like that :) I have three concerns: how and where to show that a job is in progress, how and where to report on failure, and how to get the complete set of db permissions required for the person-merge-job db user.
[17:11] <sinzui> yuck
[17:13] <sinzui> well it would be nice to show /!\ on the two persons to explain what is happening. Failures is a challenge because the job can be setup by ~registry or ~admins. allenap, we send emails to the user to confirm the merge should happen. Maybe can email the user to let him know something is wrong
[17:15] <allenap> sinzui: Yeah, that concurs with what I was thinking, except I was only going to show a /!\ on the person being merged (the "from" person).
[17:15] <sinzui> allenap: the compete set of db permissions is implied in _merge that looks for all columns that reference person. It is an awesome list
[17:17] <sinzui> allenap: while a job is in progress, the new porfile is gain parts of another. Users see some information transferred and some they now is missing. The user reports a bug or asks a question that I then explain
[17:17] <allenap> sinzui: Yes, and I assume there will be others, like tables that are touched as a side-effect of other things. I have a first run of the necessary permissions, so I thought I could make async merging available via a feature flag so that we can converge on the correct permissions. Or we could shove it in staging and keep hacking at it until we seem to have everything.
[17:18] <allenap> sinzui: It shouldn't see anything until the job is done though? It only commits at the end?
[17:18] <sinzui> allenap: and we will need to update these permission each time a person reference is added to the schema
[17:19] <allenap> sinzui: Yes. There is a test that exercises the new user, so, apart from side-effects, we should catch that before landing.
[17:19] <sinzui> allenap: I think there are parts that do not. Consider that the emaila addresses are moved before the job will start
[17:20] <allenap> sinzui: Ah, true. Eventually those actions could/should be moved into the job too.
[17:21] <sinzui> I am not sure about the emails. Merge does not actually start until the user has confirmed each email address. that can take days from the initial send
[17:21] <manish> how can I download the latest Launchpad WADL file?
[17:21] <manish> is it hosted somewhere?
[17:22] <manish> Ursinha, lifeless jml gary_poster is launchpad's WADL file hosted somewhere from where I can download it?
[17:23] <gary_poster> manish hi.  Try leonardr?
[17:23] <manish> gary_poster, I was not sure if he is there
[17:23] <leonardr> manish: the wadl file is the wadl representation of the service root
[17:24] <manish> so this means that I need to authorize the application, and then download it?
[17:24] <leonardr> so GET /[version] and ask for application/vnd.sun.wadl+xml
[17:24] <leonardr> you should not need to authorize
[17:25] <manish> leonardr, possible to download it via curl?
[17:25] <sinzui> allenap: may it would be possible to generate the list of tables in the proc that reads security.cfg. It could call listReferences(cur, 'person', 'id') to build the list. We know that the code has to declare what it will handle itself. I think stub will have to advise though
[17:25] <manish> I am working on the API after months
[17:26] <leonardr> manish: yes, let me figure out the syntax
[17:26] <sinzui> allenap: oh. there is a skip list that we know can be invalid after a merge (team poll for example).
[17:27] <leonardr> manish: curl https://api.launchpad.net/1.0/ -H "Accept: application/vnd.sun.wadl+xml"
[17:27] <manish> thanks
[17:27] <manish> trying
[17:27] <allenap> sinzui: Interesting idea :) See my last comment in https://code.launchpad.net/~allenap/launchpad/async-person-merge-162510/+merge/50919 for how I've calculated the list so far.
[17:27] <allenap> sinzui: s/list/permissions/
[17:30] <allenap> sinzui: Is your team on maintenance next week? The red squad is moving over to feature work. If you are, then would one of your team be able to take over this work? I don't think I'll get it all done tomorrow!
[17:30] <sinzui> allenap: green will be on maintenance for 4+ weeks I believe
[17:31] <sinzui> allenap: I think you can land the core work, then my squad can take up the integration issue
[17:31] <jtv> bigjools: I see you're having one of those good days with buildbot.
[17:31] <bigjools> jtv: FSVO
[17:32] <allenap> sinzui: That's great news. Okay, I'll do that, and email you to hand over.
[17:32] <jtv> bigjools: I do TLAs, not ETLAs
[17:32] <sinzui> thanks! really. This was the last timeout left in the old registry teams queue
[17:33] <bigjools> jtv: it's a shame :)
[17:35] <jtv> bigjools: I just noticed it's evening here—I ought to go.
[17:35] <bigjools> that happens to all of us
[18:11] <jcsackett> sinzui: i notice you have nested <ul> elements in your diff rather than <ul><li>; was that intentional? https://pastebin.canonical.com/43911/
[18:12] <sinzui> I suck
[18:12] <lifeless> morning
[18:12] <jcsackett> also, i just realized, you have this set to code reviewers, did you want UI, since it's mostly ui stuff?
[18:12] <sinzui> If I did it once, then I think I may have done it 3 times. I am very consistent :)
[18:12] <sinzui> oh, good
[18:13] <jml> I've got these branches here that someone might want to take over: https://code.launchpad.net/~jml/launchpad/reported-by-me-121646 , https://code.launchpad.net/~jml/launchpad/advanced-search
[18:13] <sinzui> jcsackett: The replace ensure fixes my stupidity. The template should use li as you noted
[18:13] <jml> if not, maybe I'll magically finish them.
[18:13] <deryck> Morning, lifeless
[18:13] <jml> g'night all
[18:13] <jcsackett> sinzui: ok. i'll continue reviewing with that in mind. you want me to request a ui review for this, as long as i have it open?
[18:14] <sinzui> yes, I will prepare screen caps of the root pages for henninge or huw
[18:14] <jcsackett> ok.
[18:16] <lifeless> hi deryck
[18:16] <lifeless> night jml
[18:24] <jcsackett> sinzui: you didn't actually have any other typos like that. i've highlighted the diff in a comment, but aside from the typo, r=me.
[18:30] <sinzui> jcsackett: thanks I will look the diff over again. since I am prone to repeating my mistakes exactly
[18:34] <lifeless> flacoste: ping
[18:34] <flacoste> hi lifeless
[18:35] <lifeless> quick call ?
[18:35] <flacoste> lifeless: sure
[18:41] <LPCIBot> Project devel build (472): STILL FAILING in 5 hr 27 min: https://hudson.wedontsleep.org/job/devel/472/
[18:41] <LPCIBot> * Launchpad Patch Queue Manager: [r=jml, leonardr][bug=251685,
[18:41] <LPCIBot> 586695] An implementation of the Poppy FTP server using Twisted.
[18:41] <LPCIBot> * Launchpad Patch Queue Manager: [r=abentley][no-qa][bug=723733] Clear LC_TIME for update-image.
[18:42] <abentley> LPCIBot: You mention me, but not even the original committer?
[18:44] <lifeless> it hasn't been taught to do that. should be reasonably straight forward to do so
[18:53] <LPCIBot> Project db-devel build (393): STILL FAILING in 5 hr 54 min: https://hudson.wedontsleep.org/job/db-devel/393/
[19:20] <flacoste> leonardr: can you take a look at https://code.launchpad.net/~thumper/launchpad/lp-client-yui-module/+merge/51038
[19:20] <flacoste> and see if you agree with my assessment
[19:20] <leonardr> sure
[19:21] <lifeless> flacoste: +oops and +haproxy not being allowed db access is a little annoying ;(
[19:21] <flacoste> lifeless: why? we could revert that policy
[19:21] <lifeless> lp:~lifeless/launchpad/profile
[19:21] <flacoste> it wasn't like that in the beginning
[19:21] <flacoste> what's the issue with that?
[19:22] <lifeless> it does a feature rule lookup to enable profiling
[19:22] <lifeless> it happens in beforetraversal, but we inject the null feature controller in callObject
[19:26] <flacoste> any reason it isn't injected in beforeTraversal?
[19:26] <flacoste> at the same time than the DBPolicy is set
[19:27] <lifeless> yes
[19:27] <lifeless> we need the team selector to use this on staging.
[19:27] <flacoste> instead of looking at the pageid
[19:27] <flacoste> in callObject
[19:27] <lifeless> oh, the db policy
[19:27] <flacoste> let's simply look at the DBPoilicy
[19:27] <lifeless> sorry
[19:27] <lifeless> feature controller
[19:27] <flacoste> we could even set the FeatureController using adaptation
[19:27] <lifeless> that might work
[19:28] <lifeless> I've got a very small change to my patch to get by for now
[19:58] <bac> hi deryck
[19:58] <deryck> Hi bac
[20:07] <thumper> flacoste: the problem with the current launchpad_ajax.js test is I have no idea how to wrap it
[20:07] <thumper> flacoste: also... we don't want to use sample data
[20:07] <flacoste> thumper: you mean automate it's running?
[20:07] <flacoste> or run it
[20:07] <thumper> flacoste: I'd happily fix it if we can work out how
[20:08] <flacoste> hang on
[20:08] <flacoste> so the bug has the command line to run the tests
[20:08] <thumper> flacoste: also, why do you say that the yui tests can't test the api?
[20:08] <flacoste> because they don't have the LP app server running
[20:09] <thumper> hmm...
[20:09] <flacoste> we might fix that
[20:09] <flacoste> but I'm not too sure how the io part would interact with YUI tests
[20:09] <thumper> and to answer your other question, yes I was wanting to add some tests for the cache updating :)
[20:09] <flacoste> i know yuitest supports some form of asynchronous testing
[20:10] <flacoste> but not sure it would work in practice
[20:10] <thumper> flacoste: my problem was a complete lack of understanding of the windmill tests and how to get them to integrate with the new YUI module
[20:10] <flacoste> it's a different test infrastructure
[20:10] <flacoste> the jsttests
[20:10] <flacoste> it's different from both our regular windmill tests (which uses python)
[20:10] <flacoste> and from yuitest
[20:10] <thumper> sure, but since the launchpadlib client code is now in a YUI module, is it still possible to test?
[20:10] <flacoste> it will yes
[20:10] <thumper> I'm referring to the launchpad_ajax.js test
[20:11] <thumper> flacoste: would mumble be better?
[20:11] <flacoste> thumper: we can yes
[20:11] <flacoste> thumper: i'm in blue one-on-one
[20:37] <mwhudson> jtv: no
[20:37] <flacoste> thumper: ./bin/tags -e
[20:38] <thumper> $ ./bin/tags -e
[20:38] <thumper> /usr/bin/ctags: invalid option -- 'e'
[20:38] <thumper> 	Try `/usr/bin/ctags --help' for a complete list of options.
[20:40] <flacoste> thumper: update-alternatives --list ctags
[20:40] <flacoste>  /usr/bin/ctags-exuberant
[20:50] <leonardr> thumper, flacoste, did you come to an agreement on the javascript tests? i'm late to this party
[20:54] <flacoste> leonardr: i think so, on the phone with thumper right now
[20:59] <lifeless> any reviewers around ?
[20:59] <lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-279513/+merge/51063
[20:59] <lifeless> I can't mentor wgrants review of mine own branch
[21:02] <lifeless> jcsackett: ^
[21:02] <jcsackett> lifeless: looking now.
[21:02] <lifeless> awesome, thanks
[21:13] <StevenK> thumper: Still on the phone with flacoste? Trying to decide to make breakfast or wait
[21:14] <thumper> StevenK: lets do now
[21:14] <thumper> leonardr: mumble?
[21:14] <leonardr> thumper, sure
[21:15] <leonardr> hm, the server's timing out
[21:18] <jcsackett> lifeless: in case you missed my wrong channel message, r=me.
[21:20] <thumper> wallyworld: bug 680497
[21:20] <_mup_> Bug #680497: jstests for LP JavaScript client are not running automatically <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/680497 >
[21:24] <lifeless> jcsackett: cool, thanks!
[21:36] <leonardr> thumper, when we move to maintenance, i'd really like to address this bug: https://bugs.launchpad.net/launchpad/+bug/271010
[21:36] <_mup_> Bug #271010: OOPS accessing a non-existent oauth token page. <api> <lp-foundations> <oauth> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/271010 >
[21:37] <leonardr> now that launchpadlib has been upgraded in natty, people will start getting that bug all the time
[21:37] <thumper> leonardr: sounds great, it is critical even :)
[21:37] <thumper> leonardr: I'd also like to see the lazr.restful change we talked about yesterday
[21:37] <leonardr> thumper: let me find the bug, i  think lifeless pushed back on it a little
[21:39] <lifeless> leonardr: I'd be happy to talk about it
[21:39] <leonardr> thumper: https://bugs.launchpad.net/lazr.restful/+bug/723959
[21:39] <_mup_> Bug #723959: Separate the floating "latest" version from the latest version-in-progress <lazr.restful:Incomplete> < https://launchpad.net/bugs/723959 >
[21:39] <thumper> lifeless: how about we all talk about it next week?
[21:40] <leonardr> sure
[21:40] <lifeless> thumper: sure; you know where to find me :)
[21:40] <lifeless> thumper: if you want to make a specific time, I can do that too. monday/tuesday are best; i have a hosital visit on wed and a short friday
[21:41] <thumper> lifeless: we should try early tuesday so we can get leonardr on his monday afternoon
[21:41]  * leonardr approves
[21:41] <lifeless> sure
[21:41] <lifeless> uhm, my 8am with elliot is cancelled as he's in sa
[21:42] <StevenK> South Australia?
[21:43] <lifeless> africa
[21:43] <lifeless> ensemble sprint
[21:54] <flacoste> thumper: i'm back
[22:00] <lifeless> I wonder
[22:00] <lifeless> perhaps we should have a batchnavigator for linked bugs on branches
[22:01] <wgrant> lifeless: Why?
[22:01] <wgrant> Any branch that has lots of bug links probably shouldn't have any shown at all.
[22:03] <lifeless> https://code.launchpad.net/%7Esoftware-store-developers/software-center/trunk/+index has 375 linked bugs
[22:05] <wgrant> lifeless: Hmm.
[22:06] <wgrant> Bug 721591 is Natty-critical, and we have only one or two cocoplum deployments left before release.
[22:06] <_mup_> Bug #721591: backports release files in natty and above don't have new apt metadata <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/721591 >
[22:06] <wgrant> lifeless: I thought we didn't show linked bugs on dev focuses...
[22:07] <lifeless> wgrant: we might not show it. We're doing the work.
[22:11] <lifeless> anyhow
[22:11] <lifeless> for now, I think batching will handle it fine
[22:12] <lifeless> the actual bugbranch relation should be snappy and grabbing a bug description is shallow
[22:13] <lifeless> anyone feeling LP is slower than usual *right now* ?
[22:14] <wgrant> I think I have some idea why.
[22:14] <wgrant> Testing a theory as we speak.
[22:14] <wgrant> I suspect we have extreme request backlogs.
[22:14] <lifeless> if we need to escalate, we should do so asap so as not to be waking elmo up
[22:15] <wgrant> lifeless: Requests that end in an IntegrityError hang.
[22:15] <wgrant> on staging and lpnet.
[22:15] <wgrant> I wonder if our retry limit is broken.
[22:15] <wgrant> It first appeared within the last two days.
[22:15] <wgrant> Possibly the last day.
[22:15] <lifeless> that sounds a little worrying
[22:16] <lifeless> how long do they hang for ?
[22:16] <wgrant> Ever.
[22:16] <wgrant> AFAICT
[22:16] <wgrant> We get a 502 back.
[22:16] <wgrant> After a long time.
[22:16] <wgrant> Let's see if it happens locally.
[22:17] <lifeless> 502 will be apache?
[22:17] <wgrant> server: Apache/2.2.14 (Ubuntu)
[22:18] <wgrant> Hangs locally too.
[22:18] <wgrant> Bisection time!
[22:19] <wgrant> Ah, found it.
[22:19] <lifeless> don't we have a test for this ?
[22:19] <lifeless> you're going to blame me, aren't you :)
[22:19] <wgrant> No, it was me!
[22:19] <lifeless> what is it
[22:19] <lifeless> rev #?
[22:19] <wgrant> The ZTM thing.
[22:20] <wgrant>   File "/home/wgrant/launchpad/lp-branches/secret-query-count-determinism/lib/canonical/launchpad/webapp/adapter.py", line 201, in clear_request_started
[22:20] <wgrant>     transaction.manager.unregisterSynch(_local.commit_logger)
[22:20] <wgrant> AttributeError: 'thread._local' object has no attribute 'commit_logger'
[22:20] <wgrant> Does that, looping over and over, forever.
[22:20] <wgrant> With pauses, though.
[22:20] <wgrant> The tests must replace some of the error handling machinery...
[22:21] <lifeless> \o/
[22:22] <StevenK> Hm. Four test failures on buildbot, all in devscripts.ec2test
[22:22] <jml> Sorry!
[22:22] <jml> I'll fix those now.
[22:22] <lifeless> wgrant: so, we'll have hung threads right ?
[22:22]  * jml dons the pointy hat of shame
[22:23] <wgrant> lifeless: It's not entirely clear.
[22:24] <wgrant> Diff is easy, why it exists and how to test it is not.
[22:24] <jml> StevenK: btw, did you see my suggestion to make your bot report the failing tests rather than the failing commits?
[22:24] <wgrant> Also, why it keeps retrying infinitely is also unclear.
[22:24] <lifeless> wgrant: I'm thinking about the operational impact:
[22:24] <wgrant> Because it does.
[22:24] <lifeless>  - are we on a death spiral?
[22:25] <StevenK> jml: Yes, it's a good idea, but I couldn't see a knob to tweak in the Jenkins config.
[22:25] <lifeless>  - will a service reboot *now* tide us over until the losas are up in 12 hours
[22:25] <lifeless>  - if (True, True) lets ring the escalation number and get that done
[22:25] <jml> StevenK: can't you get the junitxml & parse it in your bot?
[22:25] <lifeless> jml: it has an object model
[22:26] <StevenK> jml: It isn't my bot, it's a Jenkins plugin -- I didn't write it, I just run it :-)
[22:26] <lifeless> jml: no need to get that close to the plumbing; the bot is a plugin to hudson.
[22:26] <wgrant> lifeless: Do we have data to confirm that it is actually slow?
[22:26] <jml> lifeless: don't tell me, I'm not going to do it
[22:26] <lifeless> wgrant: not without escalating to IS
[22:26] <jml> I see.
[22:27] <lifeless> jml: the risk in speculating about implementation is that others think you're interested in implementation :)
[22:27] <StevenK> jml: I think an upstream bug report against the IRC plugin would be awesome, though
[22:27] <lifeless> wgrant: I'm going to escalate now before it gets really late
[22:28] <wgrant> lifeless: OK. We've been running the problematic code for two days now, so a restart should be fine.
[22:29] <lifeless> wgrant: can you also prepare a branch against the current deployed version, so that we can do a custom deploy if it hasn't gotten through buildbot + qa in the next 12 hours.
[22:30] <wgrant> lifeless: Sure.
[22:30] <thumper> is ec2 land fixed now?
[22:31] <wgrant> thumper: No, Windmill killed my branch.
[22:31] <wgrant> thumper: Easiest workaround is to delete jtv from your list of allowed image owners in lib/devscripts/ec2/account.py
[22:31] <sinzui> wgrant: mumble?
[22:31] <wgrant> But my thing should land in four hoursish.
[22:31] <wgrant> sinzui: Mumble production is broken mumble, but OK.
[22:32]  * thumper reverts to ec2 test and pqm-submit
[22:32] <sinzui> wgrant: That reminds. me. I think it messed with my mic again
[22:33]  * jml plays the regex slot machine game
[22:33] <jml> sinzui: I've been having troubles w/ mumble and natty since upgrading a couple of days ago.
[22:33] <StevenK> jml: Your bug about printing failing tests has been fixed upstream. I just need to actually get some time and upgrade our install
[22:33] <wgrant> Ahh, I guess tests might reuse the same thread.
[22:33] <wgrant> So the thread-local exists already.
[22:34] <sinzui> jml: yes that is when I started for me too
[22:34] <jml> sinzui: I honestly have "fix this or file a bug" on my todo list.
[22:35] <jml> OK. I think that one has taken.
[22:36] <wgrant> jml: What has it done? Muting the mic every time you reboot?
[22:36] <jml> wgrant: yeah, but also other things
[22:36] <wgrant> That's probably the alsa volume changes.
[22:36] <jml> wgrant: I can't actually get mumble to pick up sound any more
[22:36] <wgrant> Hah.
[22:36] <wgrant> Nice.
[22:36] <wgrant> My push-to-talk key broke a couple of months ago.
[22:36] <wgrant> But it works OK otherwise.
[22:36] <jml> wgrant: when I opened it, it prompted me with an audio wizard
[22:37] <wgrant> Me too.
[22:37] <wgrant> Yesterday.
[22:37] <jml> yeah
[22:37] <lifeless> wgrant: that theory is plausible.
[22:37] <jml> I didn't go through it though
[22:37] <jml> and maybe that's the problem
[22:37] <jml> I don't know.
[22:37] <jml> I just need to have half-an-hour free where that's the problem I want to solve
[22:38] <jml> I was intending to hack on Launchpad some more this evening, but I think I'm not going to.
[22:38] <jcsackett> sinzui: is there a bug # for the bugmessages => imessage thing we talked about yesterday?
[22:39] <sinzui> Oh many, let me look for one we could steal
[22:39] <jml> g'night
[22:40] <lifeless> jml: gnight
[22:44] <lifeless> wgrant: series branches show open bugs.
[22:45] <wgrant> lifeless: :(
[22:48] <sinzui> jcsackett: bug 201121 is the goal
[22:48] <_mup_> Bug #201121: Option to delete comments <chr> <feature> <lp-answers> <lp-bugs> <ubuntu-platform> <Launchpad itself:Triaged> < https://launchpad.net/bugs/201121 >
[22:48] <lifeless> \o/
[22:48] <jcsackett> sinzui: cool. it's too late to do so now, can i ping you tomorrow morning to have a bit more of a chat about it?
[22:48] <lifeless> sinzui: hide or actually delete?
[22:49] <sinzui> jcsackett: Since this is about providing ~registry and ~admins a universal script to hide offensive comments, lets set the first goal to be bug 115322
[22:49]  * lifeless is easy but reckons hide is probably sufficient for now
[22:49] <_mup_> Bug #115322: Need better protection against offensive comments and attachments from a user <canonical-losa-lp> <infrastructure> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/115322 >
[22:49] <sinzui> hide, not delete
[22:49] <jcsackett> lifeless: hide.
[22:49] <lifeless> sinzui: do we need a script? What about just a button on the comment ?
[22:50] <sinzui> jcsackett: lifeless, phase 1 move the flag on IBugMessage to IMessage and allow use to change the flag. Update three comment systems to honour the flag
[22:51] <lifeless> sinzui: I'm confused
[22:51] <sinzui> jcsackett: lifeless phase 2, allow users to mark a comment as inappropriate. Let use review the queue to hide or unmark
[22:51] <lifeless> sinzui: -very- few messages are shared between bugs. Why do we need to move the flag ?
[22:52] <sinzui> Because I will not implement something 3 times
[22:52] <lifeless> sinzui: this will have performance implications
[22:52] <sinzui> jcsackett: is welcome to implement it 3 or 5 times if he agrees to implement
[22:52] <lifeless> sinzui: the query plan filters on bugmessage at the moment, which is very very efficient
[22:53] <jcsackett> i would rather not implement 3 times, but if we need to hack something for performance, i can look at it.
[22:53] <sinzui> then I think you want to talk to jcsackett
[22:53] <lifeless> sinzui: message is a massive table by comparison; its likely to change the performance of retrieving messages in all the systems if message gets wider
[22:53] <jcsackett> lifeless: i'll have to have a longer talk with you tomorrow, i'm 5 min from EOD and need to meet people across town for an evening meeting.
[22:54] <jcsackett> but i'm definitely happy to talk.
[22:54] <lifeless> sinzui: I can certainly agree that message is the logical place
[22:54] <sinzui> lifeless:  so if we had one comment system, would you be crying?
[22:54] <lifeless> jcsackett: Its saturday tomorrow, so no promises. But ping me; if I'm around I'll be happy to talk.
[22:55] <lifeless> sinzui: I would be ecstatic if we had that *and* cruft like 'BugComment' - wtf - were gone. *and* we sort the performance stuff out.
[22:55] <jcsackett> oh right. i always remember different hours of the day. forget diff days of the week. :-p
[22:55] <lifeless> jcsackett: I probably will be around; but it will depend on lynne etc etc
[22:56] <jcsackett> right.
[22:56] <sinzui> jcsackett: keep in mind that to two bugs I showed you talk about people spamming via the UI. 90% or more are via the email gateway this year
[22:56] <sinzui> My goal is to not assign a question to a losa to get rid of the message
[22:57] <lifeless> sinzui: whats the thing one calls on a view to make it render the template (and subtemplates/portlets etc) in tests
[22:57] <lifeless> sinzui: its not just 'create_initialized_template' is it
[22:59] <sinzui> view = create_initialized_view(obj, '+name')
[22:59] <sinzui> view()
[23:00] <sinzui> well view.render() to be explicit
[23:00]  * wallyworld hates doctests
[23:00] <sinzui> lifeless: many templates want you to pass the principal kwarg to create_initialized_view()
[23:01] <lifeless> principal=a_person ?
[23:01] <wallyworld> when a test fails, it prints as "errors" all the places where there's "..." and it's hard to see the real error :-(
[23:06] <sinzui> lifeless: sorry, I got distracted. yes principal=a_person is used to setup the request
[23:06] <lifeless> sinzui: thanks!
[23:09] <lifeless> sinzui: I get this - ComponentLookupError: ((<lp.code.browser.decorations.DecoratedBranch object at 0x100bd5d0>, None), <InterfaceClass zope.interface.Interface>, '+hierarchy')
[23:09] <lifeless> sinzui: I haven't [yet] added the principal argument. Doing so now
[23:10] <sinzui> lifeless: you probably don't need the principal yet, some tales code (menus?) need it
[23:10] <lifeless> sinzui: any idea what causes that component lookup error then ?
[23:11] <sinzui> yes, I have seen that with +hierarchy. I am going to look at the lp tree. I think we need to pass a PATH arg
[23:13] <lifeless> maybe layer, or root_site?
[23:15] <sinzui> lifeless: here is an example from an old test, and an alternate how I would write it http://pastebin.ubuntu.com/571959/
[23:17] <lifeless> is path_info the canonical_url ?
[23:19] <sinzui> yes it is
[23:20] <lifeless> sinzui: http://pastebin.com/ZqKwvs2M
[23:20] <lifeless> sinzui: https://bugs.launchpad.net/launchpad/+bug/710685 is the bug I'm working on
[23:20] <_mup_> Bug #710685: Branch:+index timeouts - 3 queries triggered per linked bug <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/710685 >
[23:22] <sinzui> oh effing pagetitle
[23:22] <lifeless> create_initialized_view has constant query counts, but the page doesn't per the oops, so I want to render
[23:23] <lifeless> I could use getUserBrowser
[23:23] <lifeless> but I'm trying to find the thin line below that
[23:24] <lifeless> sinzui: where should it get the current request from ?
[23:25] <lifeless> sinzui: I see its using get_current_browser_request
[23:25] <wgrant> lifeless: In the interests of getting this out ASAP, should I land without tests? They are going to require a bit of thought and work.
[23:26] <wgrant> There's only one un-QAd rev in devel at the moment.
[23:27] <lifeless> wgrant: soit
[23:27] <sinzui> lifeless: I do not think DecoratedBranch has a registered hierarchy adapter and there is nothing in the default setup that is being used
[23:27] <sinzui> and this is death is render()
[23:28] <lifeless> yes
[23:28]  * sinzui looks at DecoratedBranch
[23:28] <lifeless> are there reasonable alternatives to a user browser within reach of a morning fiddle ?
[23:32] <sinzui> lifeless: I know what to do. I faced this when working with menus
[23:32] <sinzui> We need a helper.
[23:33] <lifeless> o/~ I need a hero o/~
[23:36] <wgrant> Total: 7 tests, 0 failures, 0 errors in 27.508 seconds.
[23:36] <wgrant> General warnings.
[23:36] <wgrant> The doctest <doctest test_adapter.txt[98]>, at the line: >>> clear_request_started()
[23:36] <sinzui> oh bugger, I may be in a Klein bottle
[23:37] <wgrant> That warning is so general that it has no content at all!
[23:39] <sinzui> lifeless: http://pastebin.com/3Bkr9ntz
[23:39] <sinzui> We need the traversed objects, so we build a request with them first
[23:40] <wgrant> lifeless: Ah, so it turns out the retry machinery is buggy.
[23:41] <wgrant> lifeless: But we have just been swallowing the warnings about the illegal clear_request_started call for years.
[23:44] <wgrant> Does anybody know how to check warnings in a doctest?
[23:44] <lifeless> they show as 'output'
[23:45] <wgrant> No :(
[23:45] <wgrant> They show as "General warnings." at the end of the test run, apparently.
[23:46] <wgrant> I guess I will try the catch_warnings decorator.
[23:59] <wgrant> lifeless: https://code.launchpad.net/~wgrant/launchpad/unbreak-request-retry/+merge/51234