[09:12] <noodles775> Hi BjornT, stub: when you've time, I've got a db review request at: https://code.edge.launchpad.net/~michael.nelson/launchpad/db-changes-build-generalisation/+merge/25587
[12:33] <adiroiban> jtv1: Hi. Is there anything I need to do for POTempalte api branch to have it approved? https://code.edge.launchpad.net/~adiroiban/launchpad/bug-525371/+merge/25423
[12:37] <jtv1> adiroiban: getting the UN to intervene in my local situation would help! :)
[12:40] <jtv1> adiroiban: seriously, it's hard under the circumstances to get anything done at the moment when you live in Bangkok.  Best to get someone else to do the bulk of the review.
[12:41] <adiroiban> jtv1: sorry to hear that. I was not aware of the unrest from Bangkok.
[12:43] <jtv1> adiroiban: getting pretty bad now...  where I live is mentioned as the hottest place.  So I'm hiding out elsewhere now.
[12:45] <jtv1> Trying to find out if we're under the curfew... the government can be very vague when they're trying not to lie.
[12:47] <jtv1> We're between 3 army bases here, meaning there's no actual fighting but not a good place to violate the curfew either.  Enough innocent passers-by have been cut down by the army.
[12:55] <danilos> adiroiban, I'll take on reviewing your branch
[14:23] <danilos> adiroiban, the cleanups you did (moving IHasTranslationTemplates around) should definitely have been a separate branch: both branches would have been much simpler to review
[14:25] <gary_poster> stub, ping?  Actually trying to review your branch
[14:25] <stub> yo
[14:25] <gary_poster> Was wondering if postgres itself keeps pg_stat_user_tables up-to-date
[14:25] <gary_poster> hey
[14:25] <stub> Yes. pg keeps them up to date.
[14:26] <stub> Magic stats tables
[14:26] <gary_poster> Gotcha
[14:26] <gary_poster> so, that stats_reset thing...
[14:26] <gary_poster> that logic says...
[14:27] <gary_poster> if pg has updated the stats since the last time we recorded ir, purge DatabaseTableStats?
[14:27] <gary_poster> s/ir/it/
[14:27] <gary_poster> I must be misreading it
[14:28] <gary_poster> wait, yeah
[14:28] <gary_poster> NowStat.seq_scan < LastStat.seq_scan
[14:28] <gary_poster> but how could that happen?
[14:28] <gary_poster> stub ^^^
[14:29] <stub> No. Sometimes PG will reset the stats to zero.
[14:29] <gary_poster> ...and then we just trash the old stats?
[14:29] <stub> If that happens, we purge.
[14:29] <gary_poster> why?
[14:29] <stub> Yup. We have no way of knowing *when* it happened, so we can't compute valid deltas
[14:30] <stub> It shouldn't happen unless someone explicitly tells pg to reset the stats, so I haven't put in any more convoluted logic than that.
[14:31] <gary_poster> ah ok
[14:32] <gary_poster> stub: so, first thought is that I'd like a comment explaining all that.  It was far from clear to me on reading.
[14:33] <stub> ok
[14:42] <henninge> danilos: wasn't there some problem with 'debug_exec', too?
[14:42] <danilos> henninge, it's fixed (original branch was against production-devel, but that doesn't make any difference for build slaves)
[14:44] <danilos> henninge, I had a bashism ("function debug_func {" instead of "debug_func()" which works everywhere)
[14:44] <henninge> danilos: ah yes, I see.
[14:45] <henninge> danilos: the python --version is pretty useless, though.
[14:45] <henninge> danilos: you should use the python in the chroot. This script is still running outside of it.
[14:45] <danilos> henninge, I know, but can't do that in the shell script :)
[14:45] <henninge> not?
[14:46] <danilos> henninge, well, chroot would first have to be set-up and that happens only at the end
[14:46] <henninge> danilos: but python works from almost anywhere.
[14:46] <henninge> let me try that ... ;)
[14:50] <henninge> danilos: yup, works. Just do "$BUILD_CHROOT/usr/bin/python --version"
[14:50] <danilos> henninge, sure
[14:51] <adiroiban> danilos: sorry about that. I can split them now if you think it will help
[14:52] <henninge> danilos: nothing else to complain ;) r=me
[14:52] <danilos> henninge, thanks
[14:52] <danilos> adiroiban, nah, too late now, I've worked my way through it, review coming soon :)
[14:53] <bac> gmb: ping
[14:53] <gmb> bac, Hi
[14:53] <bac> hi gmb, are you reviewing again this cycle?
[14:54] <gmb> bac, Yes. I've updated the REviewerSchedule and put myself back in the Tuesday EU slot, though I can go to any EU slot you'd like.
[14:54] <bac> gmb cool.  let's talk in the meeting.
[14:55] <gmb> bac, Sure.
[15:03] <gary_poster> stub (sorry had stand up call, which had technical difficulties, and now in reviewer mtg), understanding what schemaname and relname are seems to be pretty crucial to understanding what the heck is going on.  Could you explain?  I'll probably ask for a quick comment in the code so it is easier to follow along.
[15:07] <stub> schema name is the schema name. This is 'public' for all lp tables, and '_sl' for the slony ones, 'pg_catalog' for postgres internal. The relname is the table name (relation name)
[15:08] <stub> I'm just using the same names the PostgreSQL internals uses.
[15:11] <gary_poster> sure, just didn't know, and that's kinda critical to understanding the logic
[15:15] <gary_poster> stub, would ask that to be clarified (just as briefly as you just did) in the report code.
[15:15] <gary_poster> Maybe less necessary once someone is able to actually still see the results, but still.
[15:16] <gary_poster> stub, so right now we just compare INTERVAL ago to now.  Is that as much detail as you expect we'll need, or an incremental step towards producing a graph over time?
[15:18] <gary_poster> AFAICT it doesn't answer a class of questions I thought we were trying to answer: what user is responsible for certain spikes.  We'll make another tuolomne graph for that?
[15:19] <gary_poster> in any case, I'll approve with the two requests for explanatory comments.  Thank you!
[15:39] <henninge> adiroiban: tests failed again. It's the windmill tests, so not your fault most likely. Can you merge devel, again, please? I heard they have been disabled now.
[15:40] <adiroiban> henninge: but then they will fail on landing .. or not?
[15:40] <henninge> adiroiban: no, shouldn't.
[15:41] <adiroiban> I am not sure what is causing them... but they look spurious
[15:41] <adiroiban> as I also get them on devel, when running the tests on a busy old P4 computer
[15:41] <adiroiban> but it is not always the same test that fail
[15:41] <adiroiban> I will merge the devel and see how it goes
[15:50] <henninge> danilos: will you update and land your branch or did you want me to do that. I forget so easily ... ;)
[15:51] <danilos> henninge, I'll update it and land it
[15:57] <adiroiban> henninge: i have merged devel and pushed the changes
[16:04] <henninge> adiroiban: yup, that should help. See: http://paste.ubuntu.com/436183/
[16:07] <adiroiban> henninge: but bug 570380 is only about hanging ec2 test, not failing test
[16:07] <mup> Bug #570380: ec2test sometimes hangs when running the windmill test suite <build-infrastructure> <qa-needstesting> <Launchpad Foundations:In Progress by mars> <https://launchpad.net/bugs/570380>
[16:07] <henninge> hm, true ...
[16:09] <mars> adiroiban, did you see the mail to the list yesterday about spurious mailman layer failures on ec2?
[16:09] <henninge> also, that was already merged earlier
[16:09] <henninge> mars: but we already ran that revision, I just realized.
[16:09] <mars> ok, just making sure
[16:10] <adiroiban> mars: „ ec2 test will be broken for a few hours” ?
[16:10] <adiroiban> henninge: were you able to reproduce those errors on your computer?
[16:10] <mars> adiroiban, yes, and the follow-up, 'ec2 test is working again'
[16:10] <henninge> err, didn't try. You tried, didn't you?
[16:11] <henninge> mars: when was that?
[16:11] <adiroiban> henninge: yes. If I run only the failing tests, they pass
[16:11] <mars> henninge, yesterday 3pm local, so 21:00UTC?
[16:12] <henninge> mars: yes, just found it.
[16:12] <henninge> This branch failed today, though.
[16:12] <adiroiban> but if I'm running all windmill tests, I will see spurious failures
[16:12] <adiroiban> and it the same for devel
[16:12] <adiroiban> not only for my branch
[16:38] <gary_poster> danilos: the branch I was talking about is https://code.launchpad.net/~gary/launchpad/bug531071/+merge/25618 .  Could you take a look when you have a moment?
[16:40] <danilos> gary_poster, sure
[16:40] <gary_poster> thank you
[16:43] <danilos> gary_poster, r=danilo, and a suggestion on how to trigger these views on staging if you want to QA it
[16:44] <gary_poster> danilos: thank you, QA info especially appreciated
[16:51] <stub> gary_poster: hmm.... yes... I forgot to add command line arguments for historical views. I guess I should land that separately.
[17:04] <gary_poster> stub, ok cool.  however you want to work it.
[21:00] <EdwinGrubbs> sinzui, I'm starting on your mp now.
[21:00] <sinzui> EdwinGrubbs, bac did it thanks
[21:01] <EdwinGrubbs> danilos, ping
[21:09] <adiroiban> EdwinGrubbs: thanks for the review. If everthing is OK, can you also send this branch on ec2-test?
[21:09] <adiroiban> I have done a local test and everthing looks fine
[21:42] <EdwinGrubbs> adiroiban, sure, I'll land it for you.