[00:01] <wgrant> sinzui: Sure.
[00:03] <wgrant> sinzui: We're on maintenance for a little longer, then?
[00:03] <wgrant> Ah, I see the email.
[01:04] <lifeless> wgrant: to -dev? or squad only?
[01:16] <wgrant> lifeless: Squad only.
[01:17] <wgrant> lifeless: What's your opinion on BPB/SPRB URLs?
[01:17] <wgrant> Currently I'm reverting BPB to +build, and SPRB to a new +recipebuild.
[01:32] <lifeless> wgrant: works for me
[01:32] <wgrant> The BPB URL probably isn't ideal, but it's not introducing a new one so I don't care too much.
[01:33] <lifeless> yeah
[01:33] <lifeless> you could do sourcebuild or something
[01:33] <lifeless> but I think recipe build is fine
[01:34] <wgrant> Hmm, bigjools didn't start the mawson restore.
[02:23] <wgrant> sinzui: Did you want to talk about that bug at some point?
[02:38] <lifeless> I'm going to get tired of clicking 'one hour' soon, I can tell.
[02:38] <StevenK> lifeless: Hm?
[02:38] <lifeless> launchpadlib desktop integration
[02:56] <sinzui> wgrant: hi. I do want to talk about that bug. I can now now or any time in the next two hours
[03:13] <LPCIBot> Project windmill-devel build #3: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/3/
[03:22] <lifeless> anyone know what translationtemplateitem.sequence means?
[03:23] <wgrant> lifeless: It's just used to preserve the POT's order, AIUI.
[03:23]  * StevenK grumbles. I don't want to add DistroSeriesParent to the sampledata
[03:29] <lifeless> so don't
[03:29] <lifeless> I don't want you to either
[03:29] <wgrant> getById or getByID?
[03:30] <wgrant> I think the latter.
[03:30] <wgrant> But we use both.
[03:30] <wgrant> But I need to change one of them to the other.
[03:30] <wgrant> So I want more opinions.
[03:30] <lifeless> the latter
[03:30] <wgrant> Thanks.
[03:30] <lifeless> fooID
[03:30] <lifeless> is the table convention
[03:30] <lifeless> so folk will expect that elsewhere
[03:31] <wgrant> Only for SQLObject.
[03:31] <wgrant> For Storm we use foo_id.
[03:31] <lifeless> which is 90% of our ORM objects
[03:31] <wgrant> And that's not camelCase anyway.
[03:31] <lifeless> headdesk
[03:31] <lifeless> select count(*), potemplate is null from translationmessage group by potemplate is null;
[03:31] <lifeless>   count   | ?column?
[03:31] <lifeless> ----------+----------
[03:31] <lifeless>  17773385 | f
[03:31] <lifeless> where's jeroen when you need him
[03:31] <lifeless>  51852904 | t
[03:32] <wgrant> Why?
[03:33] <lifeless> to find out why tm.potemplate is set in only some rows
[03:33] <wgrant> Bah. Our Storm sugar class defines getById :/
[03:33] <lifeless> I'm looking at bug https://bugs.launchpad.net/launchpad/+bug/534203
[03:33] <_mup_> Bug #534203: Timeouts on POFile:+filter (filter by person) <lp-translations> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/534203 >
[03:34] <wgrant> lifeless: I think POTemplate is only used for non-shared translations.
[03:34] <wgrant> lifeless: Shared ones use POTMsgSet.
[03:35] <wgrant> Yeah.
[03:35] <wgrant>     def shareIfPossible(self):
[03:35] <wgrant>         """See `ITranslationMessage`."""
[03:35] <wgrant>         if self.potemplate is None:
[03:35] <wgrant>             # Already converged.
[03:35] <wgrant>             return
[03:35] <lifeless> so we'll eventually drop the column?
[03:35] <wgrant> I believe so.
[03:35] <lifeless> hmm
[03:36] <lifeless> this is a good reason not to abuse semantic fields as indicators
[03:36] <lifeless> s/reason/example of/
[03:54] <LPCIBot> Project windmill-devel build #4: STILL FAILING in 40 min: https://lpci.wedontsleep.org/job/windmill-devel/4/
[04:35] <LPCIBot> Project windmill-devel build #5: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/5/
[07:28] <LPCIBot> Project devel build #685: FAILURE in 5 hr 32 min: https://lpci.wedontsleep.org/job/devel/685/
[07:28]  * StevenK frowns at Jenkins
[07:29] <LPCIBot> Project windmill-db-devel build #231: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-db-devel/231/
[07:29] <StevenK> Oh, sigh. Jenkins hasn't got a clue how long windmill-devel takes since one build hasn't been sucessful yet.
[07:29] <wgrant> Heh.
[07:30] <StevenK> However, four slaves up and building makes me happy.
[07:30] <wgrant> But not Canonicloud.
[07:30] <StevenK> Huh?
[07:31] <wgrant> It probably doesn't make the cloud very happy.
[07:31] <StevenK> No idea, TBH, but IS haven't chased me.
[07:33] <wgrant> StevenK: Linode native IPv6 is handy. My tunneled v6 routing to Fremont is apparently 10ms faster than native v4.
[07:33] <StevenK> Mmmmm, I was going to jump when they fix the DNS to handle AAAA.
[07:34] <wgrant> You can add AAAA, but the NSes don't have AAAAs themselves yet.
[07:34] <StevenK> Which means you can't resolve v6-only anyway :-)
[07:34] <wgrant> Right :(
[07:50] <LPCIBot> Project windmill-devel build #6: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/6/
[08:15] <adeuring> good morning
[09:02] <bigjools> morning folks
[09:06] <allenap> Morning bigjools, morning gnuoy, morning all.
[09:19] <LPCIBot> Project windmill-devel build #7: STILL FAILING in 6 min 20 sec: https://lpci.wedontsleep.org/job/windmill-devel/7/
[09:20] <StevenK> Uh oh
[09:20] <wgrant> StevenK: codehosting is down.
[09:20] <wgrant> I suspect that's it, but haven't checked the logs.
[09:21] <mrevell> Morning
[09:21] <StevenK> Yeah, that's it
[09:24] <gnuoy> Morning, allenap.
[09:45] <LPCIBot> Project windmill-devel build #8: STILL FAILING in 0.53 sec: https://lpci.wedontsleep.org/job/windmill-devel/8/
[09:58] <StevenK> allenap: http://pastebin.ubuntu.com/603166/
[10:00] <LPCIBot> Project windmill-devel build #9: STILL FAILING in 0.5 sec: https://lpci.wedontsleep.org/job/windmill-devel/9/
[10:01] <StevenK> Bah, stop that, Jenkins!
[10:03] <allenap> StevenK: That looks beautiful :)
[10:07] <StevenK> allenap: Thank you :-)
[10:15] <LPCIBot> Project windmill-devel build #10: STILL FAILING in 0.48 sec: https://lpci.wedontsleep.org/job/windmill-devel/10/
[10:30] <LPCIBot> Project windmill-devel build #11: STILL FAILING in 1.6 sec: https://lpci.wedontsleep.org/job/windmill-devel/11/
[10:31] <lifeless> wheee, killed my lp vm doing a full homedir backup with lmirror (OOM killer)
[10:31] <lifeless> I think I need to check the memory footprint a little :>
[10:45] <LPCIBot> Project windmill-devel build #12: STILL FAILING in 0.5 sec: https://lpci.wedontsleep.org/job/windmill-devel/12/
[10:49] <rvba> wgrant: I'm working on a branch that will use the StormStatementRecorder to monitor the number of statements used by packagecopier.CopyChecker.
[10:49] <rvba> The goal is the measure how many queries have been added by the recently merged perm check thing ... and also to have a test to keep the number of queries under a tight leash if we add more things in the future.
[10:50] <rvba> Steven told me you might have done something like that already ... but I can't find a test that does this ... any advice?
[10:50] <wgrant> rvba: I don't have a test for copychecker itself, but some of the methods it uses are constrained (eg publishBinaries)
[10:51] <rvba> wgrant: ok ... so I guess the work I'm doing makes sense then.
[10:51] <wgrant> rvba: Yup.
[10:51] <wgrant> rvba: We do need tests for that.
[10:51] <wgrant> Just nobody's written them yet.
[10:52] <wgrant> And they're pretty easy to write these days.
[10:52] <rvba> right
[10:52] <rvba> I'll take a look at was as been done with publishBinaries.
[10:52] <rvba> wgrant: thanks.
[10:52] <rvba> s/as/has/
[10:52] <wgrant> I may have misremembered. But grep around for StormStatementRecorder to see examples.
[10:52] <rvba> I've done that yeah.
[10:53] <wgrant> I think I was going to do it, but something was still not constant enough for it to be practical.
[10:55] <rvba> I see. My plan is to see how many statements it takes on average (after having created a bunch of sources) ... have create a test with that number hardcoded so that if a changes increases the number of queries issued a lot, one will get a warning.
[10:58] <rvba> I can't think of a better way to do this given that checkCopy does quite a lot of things in one call.
[11:00] <LPCIBot> Project windmill-devel build #13: STILL FAILING in 0.51 sec: https://lpci.wedontsleep.org/job/windmill-devel/13/
[11:06] <lifeless> rvba: wgrant: the worker to look for is HasQueryCount
[11:07] <wgrant> That too.
[11:07] <rvba> lifeless: yeah, I took a recent test by Gavin that uses that as an inspiration
[11:08] <lifeless> cool
[11:08] <lifeless> if you're testing a page, RendersWith something or other is a wrapper
[11:11] <rvba> I've only tested a few things ... but it does not seem to be constant (or maybe I have not properly cleaned up the cache) ... with 30 sources I've an avg of 12.23 (.23?) queries, with 300 sources the avg becomes 12.023
[11:12] <rvba> maybe I should stick to testing small individual methods as opposed to the whole checkCopy method.
[11:15] <LPCIBot> Project windmill-devel build #14: STILL FAILING in 0.49 sec: https://lpci.wedontsleep.org/job/windmill-devel/14/
[11:30] <LPCIBot> Project windmill-devel build #15: STILL FAILING in 1.3 sec: https://lpci.wedontsleep.org/job/windmill-devel/15/
[11:32] <henninge> Why is PQM rejecting my landings?
[11:33] <henninge> Command failed!
[11:33] <henninge> running 0 tests...
[11:33] <henninge> ----------------------------------------------------------------------
[11:33] <henninge> Ran 0 tests in 0.000s
[11:33] <wgrant> henninge: What's in the attachments it sends back?
[11:33] <wgrant> We are probably in testfix.
[11:33] <wgrant> stdout should tell you.
[11:33] <henninge> it does
[11:33] <wgrant> Looks like buildbot is a bit unhappy. I've forced it.
[11:34] <henninge> why is that not in the mail itself ...
[11:34] <wgrant> No idea :/
[11:34] <henninge> it used to be
[11:34] <henninge> wgrant: tanks
[11:34] <henninge> thanks
[11:35] <StevenK> henninge: It's because PQM is terrible
[11:36] <henninge> how have we been planning to switch to tarmac?
[11:37] <henninge> PQM script success ;-)
[11:42] <bigjools> wgrant: we can't land StevenK's changes to use DSP on prod as he's got more schema changes.  Can you think of anything that will break in oneiric if we change its parent_series for a month?
[11:43] <wgrant> bigjools: Translations might.
[11:43] <wgrant> bigjools: Although hopefully only initialisation uses that.
[11:43] <bigjools> yeah
[11:43] <bigjools> it's been initialised, so ... I am looking for anything else
[11:44] <LPCIBot> Yippie, build fixed!
[11:44] <LPCIBot> Project db-devel build #513: FIXED in 5 hr 32 min: https://lpci.wedontsleep.org/job/db-devel/513/
[11:44] <bigjools> LPCIBot gets a woody
[11:44] <wgrant> bigjools: SourcePackage.packaging uses it...
[11:44] <wgrant> Which may break bug linking.
[11:45] <bigjools> easily fixed
[11:45] <LPCIBot> Project windmill-devel build #16: STILL FAILING in 0.55 sec: https://lpci.wedontsleep.org/job/windmill-devel/16/
[11:47] <wgrant> I'm thinking about getBuildByArch.
[11:47] <wgrant> It's *probably* not going to matter, but it's hard to be sure immediately.
[11:48] <bigjools> bug 643369
[11:48] <_mup_> Bug #643369: IDistroSeries.deriveDistroSeries() should use the security adapter <derivation> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/643369 >
[11:52] <bigjools> wgrant: euargh
[11:52] <bigjools> that code is gross
[11:53] <wgrant> And slow.
[11:53] <wgrant> Damn slow.
[11:53] <bigjools> wgrant: wtf does it need to traverse over parent_series - it should just go backwards over versions
[11:53] <wgrant> bigjools: :/
[11:54] <bigjools> although, we didn't make distroseries.version a debversion did we?
[11:54] <bigjools> yeah, that will break horribly if we change parent_series.  Damn.
[11:57] <wgrant> I'm not sure the breakage will matter.
[11:59] <bigjools> wgrant: it might break build uploads
[11:59] <bigjools> actually
[11:59] <bigjools> wtf
[12:00] <bigjools> ah it was only used for security uploads
[12:00] <bigjools> the old style
[12:00] <LPCIBot> Project windmill-devel build #17: STILL FAILING in 0.56 sec: https://lpci.wedontsleep.org/job/windmill-devel/17/
[12:01] <wgrant> bigjools: Yes.
[12:01] <wgrant> bigjools: Well, not entirely.
[12:01] <wgrant> It only creates builds for that case.
[12:02] <wgrant> But it will use parent_series when searching for existing builds too.
[12:02] <wgrant> eg. in createMissingBuilds.
[12:02] <wgrant> But that's probably not relevant here.
[12:02] <bigjools> yeah, but it relies on getBuildByArch working
[12:02] <wgrant> Since everything should be found in the series itself.
[12:02] <bigjools> if it finds nothing it'll start creating new builds
[12:15] <LPCIBot> Project windmill-devel build #18: STILL FAILING in 1.5 sec: https://lpci.wedontsleep.org/job/windmill-devel/18/
[12:18]  * StevenK cleans up after that
[12:19] <StevenK> Right. Slave deleted, build scheduled.
[12:37] <LPCIBot> Yippie, build fixed!
[12:37] <LPCIBot> Project devel build #686: FIXED in 5 hr 8 min: https://lpci.wedontsleep.org/job/devel/686/
[12:38] <danilos> lifeless, I see you declined a request to join 'launchpad' team into malone-alpha with "a flag would be better": we do have a flag, but we've set it to team malone-alpha, and we'd like to expand that a step at a time, so if we can't have multiple team rules, can we please add it? (unless other stuff has been arranged in the meantime)
[12:39] <danilos> lifeless, and hi :)
[12:40] <wgrant> danilos: You should be able to have multiple team rules.
[12:40] <wgrant> danilos: Does it not work?
[12:41] <danilos> wgrant, I don't know, I never knew it was supposed to work
[12:42] <wgrant> danilos: It will scan through until it finds a rule that matches.
[12:42] <wgrant> From highest priority to lowest.
[12:42] <wgrant> There was a bug until last week that meant the 'default' scope took precedence, but multiple team rules should have worked anyway.
[12:42] <danilos> wgrant, cool, I'll try that then
[13:19] <danilos> losa ping: hi, just to check, if we want feature flags changed/added to, I should use LPS "DB query" section or what'd be the preferred way to communicate them?
[13:19] <mthaddon> danilos: that's fine, yep
[13:20] <danilos> mthaddon, cool
[13:37] <LPCIBot> Project windmill-devel build #19: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/19/
[13:51] <deryck> Morning, all.
[13:58] <deryck> adeuring, abentley, I'll be about 5 minutes late for standup.  Sorry.
[13:59] <adeuring> deryck: that gives me time to make a coffee :)
[13:59] <abentley> deryck: okay.
[14:07] <deryck> adeuring, henninge -- could be the wifi point I'm using
[14:08] <deryck> adeuring, I'm mooching off the church next door until att arrives :-)
[14:09] <abentley> deryck: have you started?
[14:09] <deryck> abentley, trying to start, connection or mumble not working for me
[14:09] <abentley> deryck: ah.
[14:10] <deryck> abentley, henninge, adeuring -- yeah, just hold the standup and I'll listen
[14:14] <deryck> if only you could hear me, henninge
[14:14] <deryck> abentley, adeuring, henninge -- thanks, guys!
[15:28] <jcsackett> if i'm adding a class to something in YUI to change its display (in this instance, color), do i have to do anything beyond addClass?
[15:31] <jcsackett> ah, no i do not, but it helps to get the classname right.
[15:32] <sinzui> henninge: ping
[15:32] <henninge> Hi sinzui!
[15:34] <LPCIBot> Project windmill-devel build #20: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/20/
[15:34] <sinzui> henninge: +1 for your fix, but I am not sure you fixed the actual bug since your encoding line is like the original test.
[15:35] <henninge> sinzui: it is testing for multiple lines now, is it now?
[15:35] <henninge> s/now/not/
[15:35] <sinzui> henninge: I think I am running the checkers in the wrong order. The text checker that sets utf_8 must run first, not last
[15:35]  * henninge thought it did
[15:40] <benji> sinzui: I'm really happy with the improvements you suggested to the UI review yesterday, it's ready for another review when you have the time: https://code.launchpad.net/~benji/launchpad/click-to-close-boxes/+merge/59818
[15:40]  * sinzui looks
[15:41] <henninge> sinzui: ah, now I see. text_check runs last.
[15:43] <sinzui> benji: r=me
[15:43] <benji> great, thanks
[15:43] <sinzui> henninge I can make the ordering change if you do not have time. I should have noticed my stupidity years ago
[15:44] <henninge> sinzui: I can add it, np.
[15:44] <sinzui> henninge: ping me when you want me to merge it into trunk
[15:45] <henninge> sinzui: I don't think it need a test, does it?
[15:45] <sinzui> It does not
[15:48] <henninge> sinzui: pushed, you can merge now.
[15:48] <sinzui> thanks. If the builder at available, this will arrive in the lp ppa in a few hours.
[15:49] <bigjools> sinzui: have you seen the queue? :)
[15:49] <sinzui> yes
[15:49] <sinzui> :(
[16:02] <maxb> Whats the package?
[16:02] <maxb> Oh, and that reminds me
[16:02] <maxb> Would someone like to review my lpreview-body packaging fix?
[16:02] <benji> mrevell: I added a comment to https://bugs.launchpad.net/launchpad/+bug/771231 that asks you to comment on/approve the fix.
[16:02] <maxb> https://code.launchpad.net/~maxb/lpreview-body/fix-package/+merge/59137
[16:02] <_mup_> Bug #771231: There is no confirmation of what I've done after I create a structural subscription <exploratory-testing> <qa-needstesting> <story-better-bug-notification> <Launchpad itself:Fix Committed by benji> < https://launchpad.net/bugs/771231 >
[16:02] <mrevell> thanks benji, /me looks
[16:02] <maxb> You fail, _mup_
[16:02] <bigjools> sinzui: poke me the build ID and I'll get it building quicker
[16:02] <maxb> Oh, whoops, I fail
[16:03] <benji> maxb: heh :)
[16:04] <sinzui> bigjools: I do not think this is necessary. I think we can wait as long as a week to propagate this fix to all the ppas.
[16:04] <mrevell> benji, That's superb. Thanks. Tag changed to qa-ok.
[16:04] <benji> mrevell: great, thanks
[16:05] <maxb> abentley: Hello. I have a review pending for lpreview-body. It has been missed because lpreview-body is not part of launchpad-project. Could you (as project maintainer) consider amending that?
[16:06] <abentley> maxb: sure.
[16:08] <abentley> maxb: however, I'd say the reason that branch has been missed is because it's for packaging, about which I know little.
[16:13] <jml> sinzui: I see there's been a fair bit of discussion on bug 80902 recently. Anything I should be sticking my nose into?
[16:13] <_mup_> Bug #80902: Can't target bug report from project to distribution, or vice versa <bugs> <disclosure> <escalated> <javascript> <linaro> <lp-bugs> <questions> <ubuntu-qa> <Launchpad itself:Triaged by launchpad-green-squad> < https://launchpad.net/bugs/80902 >
[16:15] <sinzui> jml: I do not know. I am certain the work is harder than most people suppose, and I am certain there is a lot over lap with disclosure
[16:15] <sinzui> jml: At the worst, out work on pickers will make that bug easy to fix. at best, we fix that bug
[16:15] <jml> sinzui: ok.
[16:16] <sinzui> At the worst, *our* work on pickers will make that bug easy to fix. at best, we fix that bug
[16:16] <jml> sinzui: are you planning on starting the picker stuff while on maint?
[16:16] <LPCIBot> Project windmill-devel build #21: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/21/
[16:17] <sinzui> I have not committed to it, but I was looking at the timouts and ui issues in the vocabs yesterday.
[16:18] <jcsackett> sinzui: have you ever encountered in YUI work the method hasClass failing to work in if else statements?
[16:19] <sinzui> jcsackett: no.
[16:19] <sinzui> jcsackett: can I see a paste of the code
[16:21] <jcsackett> sinzui: http://paste.ubuntu.com/603311/
[16:22] <sinzui> jcsackett: I think hasClass() is at fault
[16:23] <sinzui> jcsackett: isn't it always returning True
[16:23] <jcsackett> sinzui: no. if the class isn't on the element i see false.
[16:23] <jcsackett> if i do like {{{ alert(hidden); }}}
[16:24] <sinzui> jcsackett: then you are saying addClass() does not work
[16:26] <sinzui> jcsackett: have you tried something simpler, like toggleClass()
[16:27] <jcsackett> sinzui: i didn't know such a thing existed.
[16:27] <jcsackett> sinzui: still, here's the thing, i can set up conditions so that hasClass comes back false.
[16:27] <sinzui> jcsackett: http://developer.yahoo.com/yui/3/api/Node.html
[16:27] <jcsackett> but the "true" evaulation still fires off.
[16:29] <abentley> jcsackett: See my Javascript Learnings #3.
[16:31] <jcsackett> abentley, sinzui: i can see how toggleClass does the same thing i'm doing, but it doesn't explain why when hasClass is return 'false' the if clause is evaluting for 'true'.
[16:31] <jcsackett> i'll move on, but this bugs me.
[16:31] <jcsackett> clearly there's a gotcha or subtlety i don't get.
[16:31] <rvba> jcsackett: is hidden a boolean all right? (this bugs me too ;))
[16:32] <sinzui> jcsackett: write the if like if (hidden == true) { to determine if you are a victim of coercion.
[16:32] <abentley> jcsackett: what is hidden_class ?  You're not defining it in the snippit you posted.
[16:33] <jcsackett> hidden_class = "adminHiddenComment"
[16:35] <abentley> jcsackett: I wonder if hidden_class is evaluating to undefined?  I don't know how hasClass would behave with that input.
[16:36] <rvba> jcsackett: I would make sure 'hidden' is of the right type ... a boolean being 'true' or 'false' always evaluated to 'true' in a test is kinda strange.
[16:39] <adeuring> abentley: could you have alook at this (small) MP: https://code.launchpad.net/~adeuring/launchpad/bug-746866/+merge/59954 ?
[16:40] <abentley> adeuring: sure.
[16:40] <adeuring> thanks!
[16:43] <wallyworld> sinzui: hi. i've recently arrived in Budapest. 38 hours with little sleep. running on caffine. gotta stay awake for the welcome dinner :-) when you have a moment, could you please take another look at this mp? i've reworked the implementation to address the issues raised with the first approach. https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/59154
[16:44]  * sinzui does
[16:55] <abentley> adeuring: r=me, but the spacing change on line 30 of the patch looks wrong.
[16:56] <adeuring> abentley: oops... I'll fix it. thanks for the review!
[16:56] <abentley> adeuring: np
[17:17] <sinzui> wallyworld: r=me
[17:17] <wallyworld> sinzui: thanks.
[17:28] <bigjools> we really need to move the "What next" at the bottom of +filebug to the top-right menu.
[17:30] <bigjools> talking of which, someone will get bug 777777 today
[18:03] <bigjools> good night all
[19:12] <LPCIBot> Project windmill-db-devel build #232: STILL FAILING in 1 hr 15 min: https://lpci.wedontsleep.org/job/windmill-db-devel/232/
[19:15] <cody-somerville> OOPS-1950CQ433
[19:21] <sinzui> deryck: do you have a few minutes to mumble?
[19:23] <deryck> sinzui, I do, sure.  I had mumble issues before though.  so you can help me test too
[19:25] <deryck> sinzui, I hear you
[19:25] <deryck> sinzui, let me log off and work on sound and come back
[19:25] <sinzui> okay
[19:26] <deryck> I assumed it was bad wifi this morning
[19:27] <sinzui> deryck: My sound is set to use pulse, I do not see any hacks for the sound driver in /etc/modprobe.d  anymore
[19:27] <dobey> maybe your wifi got stolen too, from PSN
[19:27] <deryck> ah, that's it!
[19:27] <deryck> actually that does help....
[19:28] <deryck> I was hacking sound to get games running under wine with no psn ;)
[19:28] <deryck> I had forgot
[19:28] <dobey> heh
[19:28] <dobey> glad to be so helpful :)
[19:28] <LPCIBot> Project windmill-devel build #22: STILL FAILING in 1 hr 4 min: https://lpci.wedontsleep.org/job/windmill-devel/22/
[19:32] <deryck> sinzui, right
[19:33] <deryck> sinzui, I'll try again.  maybe it wasn't anything gaming related then ;)
[19:33] <sinzui> I do not see your icon changing, My computer does not think you are talking
[19:33] <deryck> sinzui, logging off while I futz with settings again
[19:33] <lifeless> flacoste: https://bugs.launchpad.net/launchpad/+bug/534203/comments/10 may interest you
[19:33] <_mup_> Bug #534203: Timeouts on POFile:+filter (filter by person) <lp-translations> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/534203 >
[19:33] <deryck> sinzui, and I've got solid red lips on my end.  but the sound settings all seem ok on my end
[19:33] <lifeless> flacoste: cold cache we're 60 seconds for the relevant query
[19:33] <lifeless> flacoste: tis a miracle it works at all
[19:34] <lifeless> flacoste: the most expedient solution would be main memory > db size for all db servers.
[19:34] <lifeless> flacoste: this would scale badly because we have complete replicas, no partitioning
[19:34] <lifeless> danilos: hi
[19:35] <lifeless> danilos: are you still around?
[19:36] <flacoste> lifeless: i'll ask charlie/elmo about what's the RAM situation nowadays with our DB servers
[19:36] <flacoste> not sure we can get more
[19:36] <lifeless> flacoste: I want to hear elmos voice when we ask about a 250GB upgrade.
[19:36] <lifeless> flacoste: so it can wait for our biweekly ISP call :>
[19:36] <flacoste> lifeless: :-)
[19:37] <lifeless> flacoste: for clariry - I'm not recommending this option at this point
[19:37] <lifeless> flacoste: just noting that we're starting to hit things which we can't reasonably expect to be hot given our 3:1 db:memory ratio
[19:38] <deryck> sinzui, I take it you can't hear me again
[19:38] <flacoste> lifeless: on an unrelated note, we should address bug 297052 at some point
[19:38] <_mup_> Bug #297052: Webservice requests never use a slave database because last-write time is unknown <api> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297052 >
[19:38] <flacoste> given that we have a 2:1 API to web ratio
[19:39] <lifeless> flacoste: indeed; or change our scaling tech and obsolete that :>:>
[19:39] <flacoste> now that we support read-only API requests, we might trivially send all of them to slaves
[19:39] <lifeless> anonymous ones - for sure
[19:39] <flacoste> not sure how much of our traffic is anonymous API though
[19:40] <sinzui> deryck: https://dev.launchpad.net/Registry/ProjectReview
[19:43] <lifeless> benji: thanks
[19:43] <benji> my pleasure
[19:44] <lifeless> jml: btw - subunit trunk -> py3 ok
[20:00] <LPCIBot> Project windmill-db-devel build #233: STILL FAILING in 48 min: https://lpci.wedontsleep.org/job/windmill-db-devel/233/
[20:09] <LPCIBot> Project windmill-devel build #23: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/23/
[20:11] <flacoste> lifeless: i think i'll leave the total time column in, i do use it for sorting to see what page are high-impact (hits * mean)
[20:12] <lifeless> flacoste: high impact in what way
[20:12] <flacoste> lifeless: free more resources, drop significantly our oops count
[20:13] <flacoste> although the later could be get at by sorting on total hits on the timeout candidate report
[20:13] <flacoste> and the first one may be dubious
[20:13] <lifeless> flacoste: so, for oops count the profile of oopses in the oops summaries is more reliable
[20:13] <lifeless> flacoste: e.g. questions rarely oops (though they do) even though they have 50 second long requests
[20:14] <flacoste> (i do have the changes made on a local branch, just got doubts when about to submit it)
[20:14] <lifeless> flacoste: as a metric of footprint on the system sum of time spent processing isn't unreasonable
[20:15] <lifeless> flacoste: but it doesn't tell us much about the fat in the page
[20:15] <flacoste> and less is more
[20:15] <lifeless> flacoste: something like fat-in-page*hits would be an interesting order
[20:15] <flacoste> so let's remove it
[20:15] <flacoste> how would you assess fat-in-page?
[20:16] <lifeless> I don't know
[20:16] <lifeless> :)
[20:16] <lifeless> uhm
[20:17] <lifeless> high sql *count* would be a reasonable first metric.
[20:17] <lifeless> so 99the percentile of sql query count * hits
[20:18] <lifeless> as a broad proxy for inefficient + high use
[20:19] <lifeless> (not 99th percentil of sql *time*, because things like bug search are not inefficient, they are slow backends - and as such not fat on page but need redesign/new systems
[20:19] <lifeless> 99th% by time doesn't need the ht count multiplier to be useful I guess is my point
[20:20] <flacoste> ok, i'll remove the total_time column
[20:20] <flacoste> not sure about the real usefulness of the 'Fat-in-page' column, i'll add it and let's remove it later if it's doesn't see usage
[20:22] <lifeless> ok!
[20:23] <lifeless> it will be interesting to see if it lines up with the oops report
[20:27] <flacoste> lifeless: actually, looking at it locally, it seems pretty useless :-/
[20:27] <flacoste> all the top-pages are high hits low sql statements
[20:27] <vokoda`> when I try to view a file on launchpad with a file_id param I get a redirect loop error - is this a launchpad or loggerhead bug? is there a report?
[20:28] <lifeless> flacoste: with real data?
[20:28] <flacoste> lifeless: well, a subset of real data
[20:28] <flacoste> lifeless: (the log of one app server)
[20:28] <lifeless> vokoda`: that would be a loggerhead bug, I think there is a bug filed already
[20:29] <lifeless> flacoste: so, that suggests that our massively assymettric app will benefit more by reducing the sql count slightly on high frequency pages than by reducing it on low frequency pages
[20:29] <flacoste> lifeless: it does, yeah
[20:29] <lifeless> flacoste: its the basic input into a pareto analysis
[20:29] <flacoste> if we would want to drive DB usage down
[20:30] <lifeless> flacoste: I would like to see it for a bit, if thats ok
[20:30] <vokoda`> lifeless: yep just found it, filed just 10 days ago.. I'm sure this bug's been around much longer
[20:30] <flacoste> on the top50.html report, the lowest hits*sql statements is /+bugtarget-portlet-bugfilters-stats
[20:30] <lifeless> flacoste: that matches my intuition
[20:30] <flacoste> and the highest one is api/beta/ubuntu
[20:31] <lifeless> flacoste: cool
[20:31] <lifeless> flacoste: so this makes it useful:
[20:31] <flacoste> and api/beta/ubuntu is 276 more 'important' than the stats portlet
[20:31] <lifeless>  /+bugtarget-portlet-bugfilters-stats is rare we know, and we know it has issues because the thing is in the oops + timeout candidates
[20:31] <flacoste> according to that metric
[20:32] <flacoste> fair enough, i'll merge this change
[20:32] <jcsackett> sinzui: mumble?
[20:33] <sinzui> jcsackett: sure
[20:34] <lifeless> flacoste: so you're looking by url thre
[20:34] <lifeless> flacoste: if you look by pageid
[20:35] <lifeless> dum de dum browsers hate these pages
[20:35]  * flacoste waits for the JS script to finish rendering
[20:36]  * flacoste makes note to try those in chromium
[20:37] <lifeless> flacoste: Distribution:EntryResource
[20:37] <lifeless> 231101 hits
[20:37] <lifeless> 0.36 99th percentile
[20:37] <flacoste> Bug:EntryResource ,  BugTask:+index, DistroSeries:EntryResource
[20:37] <flacoste> are the top ones
[20:37] <flacoste> (on my local report)
[20:38] <lifeless> 33 statements 99th percentile
[20:38] <lifeless> thats quite a few :)
[20:39] <flacoste> 132 of BugTask+index
[20:39] <flacoste> for
[20:39] <flacoste> 48 for Person:EntryResource
[20:39] <lifeless> Bug:EntryResource 779685
[20:39] <flacoste> yeah, i think this will be interesting
[20:39] <lifeless> 43 99th percentile sql statements
[20:56] <lifeless> breakfast time
[21:13] <lifeless> abentley: bug 739921 - I think you may have missed a subtlety in the filing, I've made it more clear and reopened it
[21:13] <_mup_> Bug #739921: The link "see all merge proposals" on person/product/+activereviews 404s <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739921 >
[21:25] <abentley> lifeless: good catch.
[21:28] <LPCIBot> Project windmill-devel build #24: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/windmill-devel/24/
[22:15] <LPCIBot> Project windmill-devel build #25: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/25/
[22:36] <deryck> Later on everyone
[23:12] <lifeless> jml: still up?
[23:17] <lifeless> wgrant: recipe + binary builds
[23:17] <lifeless> wgrant: is there any reason we shouldn't insert the binary build when a recipe finishes at the same point in the queue that the recipe was (e.g. front)
[23:53] <lifeless> I'm not sure how to qa http://launchpad.net/bugs/773261
[23:53] <_mup_> Bug #773261: The permission check for syncing packages on the differences pages (+localpackagediff) should be done on a per-package basis and not by checking lp.Edit on the series. <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/773261 >