[00:00] <wgrant> mwhudson: Once the build finishes, buildd-manager should copy it into an upload directory and set the status to UPLOADING.
[00:00] <mwhudson> i wonder how much faster the chroot would unpack on arm if it was gzipped not bzip2ed
[00:00] <wgrant> We then need to run a separate script to upload it.
[00:00] <mwhudson> ah right, this is the stuff that's changed recent
[00:00] <mwhudson> ly
[00:00] <wgrant> Like 8 hours ago, yes.
[00:01] <wgrant> So I haven't run it yet.
[00:01]  * wgrant fixes that.
[00:01] <jml> speaking of changes
[00:01] <jml> I'm now running a couple of ec2 runs with my new, improved ec2 error mail
[00:05] <jml> email looks something like: http://paste.ubuntu.com/497325/
[00:06] <mwhudson> wgrant: it's "Uploading build  on Bob The Builder" now
[00:06] <mwhudson> (this looks like progress)
[00:07] <wgrant> mwhudson: Excellent.
[00:07] <wgrant> So, now you need to run...
[00:08] <mwhudson> scripts/process-upload.py ?
[00:08] <wgrant> ./scripts/process-upload.py --builds -C buildd -vvv /var/tmp/builddmaster
[00:08] <wgrant> I think that should work.
[00:08]  * mwhudson tries science
[00:09] <mwhudson> wgrant: http://pastebin.ubuntu.com/497326/
[00:09] <wgrant> mwhudson: I think it worked.
[00:10] <mwhudson> not quite sure what the bottom two bits are about, probably from the fun i had yesterday
[00:10] <wgrant> Except that there were two other uploads from the breakage yesterday.
[00:10] <wgrant> Does the build have binaries listed now?
[00:10] <mwhudson> wgrant: yes
[00:10] <Ursinha> lifeless, hello
[00:11] <mwhudson> process-accepted, publish-distro?
[00:11] <wgrant> mwhudson: OK, so it's all working.
[00:11] <wgrant> Right.
[00:11] <Ursinha> lifeless, I'm in an oops tools minisprint with matsubara-afk
[00:11] <mwhudson> wgrant: if you edit the page, you might want to scatter some -vv s around i think
[00:11] <lifeless> Ursinha: hi
[00:11] <wgrant> mwhudson: I might indeed.
[00:11] <lifeless> Ursinha: I am blocked; I need a hand
[00:12] <lifeless> Ursinha: I cannot diagnose why https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt shows 11557 as qa-notok
[00:12] <mwhudson> although wow scripts/publish-distro.py --ppa -vv is noisy
[00:12] <lifeless> Ursinha: I *thought* we had more output than that.
[00:12] <wgrant> mwhudson: Most of it was still written on July 22nd last year, so it's not exactly as I'd do it now!
[00:12] <lifeless> Ursinha: and I'm wondering where it goes so that I can see it.,
[00:12] <mwhudson> wgrant: :)
[00:12] <lifeless> Ursinha: (and the rest of the canonical staff should be able to look at it too)
[00:12] <Ursinha> lifeless, take a look here: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
[00:12] <mwhudson> and yay, i can download a build
[00:13] <wgrant> mwhudson: Is p-a happy?
[00:13] <lifeless> Ursinha: that looks old
[00:13] <mwhudson> wgrant: seems so
[00:13] <lifeless> Ursinha: because 11555 is live on production
[00:13] <Ursinha> lifeless, it's not final, just showing you what must be the report
[00:14] <lifeless> Ursinha: let me try a different angle.
[00:14] <lifeless> Ursinha: we *had a totally useable debug report*
[00:14] <lifeless> Ursinha: what happened to it?
[00:14] <Ursinha> lifeless, wait, I need context, reading devpad logs
[00:15] <Ursinha> been in a totally different context the whole day
[00:15] <lifeless> Ursinha: ok, lets start over.
[00:15] <Ursinha> lifeless, just give me a moment
[00:15] <jml> anyway, see you crazy cats later.
[00:15] <lifeless> Ursinha: hi, I've been doing CP's to lpnet based on the qatagger output; and getting folk to QA stuff as needed for ut.
[00:15] <lifeless> *it*
[00:15] <lifeless> Ursinha: sure; /me hits the pause button
[00:15] <Ursinha> thanks :)
[00:17] <mwhudson> wgrant: it seems to have worked
[00:18] <wgrant> mwhudson: Great.
[00:18] <wgrant> mwhudson: Docs updated.
[00:18] <wgrant> With the new process-upload invocation, and liberal application of -v.
[00:19] <Ursinha> lifeless, when was 11555 deployed?
[00:19] <Ursinha> lifeless, please, refresh the html report
[00:19] <lifeless> Ursinha: this morning
[00:19] <Ursinha> lifeless, always consider the txt report accurate
[00:20] <Ursinha> the html one is experimental
[00:20] <lifeless> Ursinha: so, I think we want to keep the txt report as it is too -  because its safe to show e.g. wgrant
[00:20] <lifeless> Ursinha: whereas the html report can potentially report on security bugs
[00:20] <Ursinha> lifeless, not sure what you mean; txt are for losas, html for developers
[00:20] <lifeless> Ursinha: but the html still doesn't address my question
[00:20] <Ursinha> roughly speaking
[00:21] <lifeless> Ursinha: why is 11557 blocked?
[00:21] <Ursinha> lifeless, I need to finish some tests and will put that in production, so we'll have both
[00:21] <mwhudson> wgrant: thanks for the help
[00:21] <lifeless> Ursinha: it wasn't mentioned by the commit message
[00:21] <Ursinha> lifeless, linked to the branch
[00:22] <lifeless> Ursinha: its an in-progress bug later on the branch
[00:22] <Ursinha> the problem I told you reusing branches would cause
[00:22] <lifeless> fair enough
[00:22] <wgrant> mwhudson: np
[00:22] <lifeless> there's a bug open to support this better though?
[00:22] <Ursinha> because neither ec2 or bzr lp-land or the tagger support this use case
[00:22] <Ursinha> lifeless, of course
[00:22] <lifeless> Ursinha: coolio
[00:22] <wgrant> librarian downloads are slow :(
[00:22] <wgrant> I wonder why.
[00:23] <lifeless> Ursinha: could you please tell the txt report to refresh ?
[00:23] <mars> lifeless, the HTML report says bug 618375 has not been QA'd.  the 'qa-notok' status should really be 'qa-needstesting'.  However, the bug has no tags?
[00:23] <_mup_> Bug #618375: BugTrackerSet:+index consistently slower than 10 seconds <qa-ok> <timeout> <Launchpad Bugs:Fix Committed by lifeless> <https://launchpad.net/bugs/618375>
[00:23] <Ursinha> lifeless, bug 638468 for ec2 land, bug 640566
[00:23] <_mup_> Bug #638468: ec2 land: do not include already fix-committed or fix-released bugs in commit message <new-merge-workflow> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/638468>
[00:23] <lifeless> Ursinha: I recognise I'm shooting myself in the foot
[00:23] <_mup_> Bug #640566: qa-tagger should not consider linked bugs to branches when bugs are already Fix Released <new-merge-workflow> <qa-tagger:Triaged by ursinha> <https://launchpad.net/bugs/640566>
[00:23] <Ursinha> for qa-tagger
[00:23] <lifeless> mars: it has no tags because its from later on; its further work.
[00:23] <Ursinha> yes, hehe
[00:23] <Ursinha> that's what reusing branches cause
[00:23] <lifeless> Ursinha: the big reason to handle reused branches properly is developers shouldn't need to remember if they used the name before.
[00:24] <Ursinha> but I'm working on a workaround
[00:24] <lifeless> Ursinha: we should 'just work'
[00:24] <lifeless> Ursinha: cool, and thanks.
[00:24] <Ursinha> lifeless, that's fine, I'm just saying this case wasn't considered
[00:24] <lifeless> yeah
[00:24] <lifeless> Ursinha: theres another case I think we missed.
[00:24] <lifeless> look at rev 11566
[00:24] <Ursinha> and that's why such things are happening
[00:24] <mwhudson> wgrant: what does
[00:24] <lifeless> this was one part of a 2-part branch
[00:25] <mwhudson> 2010-09-20 23:24:03 WARNING Upload was rejected:
[00:25] <mwhudson> 2010-09-20 23:24:03 WARNING 	nominatedarchindep is not present in legal_archseries: armel
[00:25] <mwhudson> mean?
[00:25] <mwhudson> oh i think i know
[00:25] <mwhudson> the upload contains _all packages and i only have a armel builder configured
[00:25] <wgrant> What's nominatedarchindep set to?
[00:25] <Ursinha> lifeless, let me see
[00:26] <mwhudson> no idea
[00:26] <mwhudson> it's on distroseries?
[00:26] <wgrant> It should be on distroseries:+edit
[00:26] <wgrant> Or maybe +admin.
[00:26] <wgrant> Set it to armel.
[00:26] <lifeless> Ursinha: so this is fixable by a rollback
[00:26] <lifeless> Ursinha: -or- by doing a fix
[00:26] <mwhudson> ah, wasn't the package i wanted to build anyway
[00:26] <lifeless> Ursinha: so we need a matching thing like rollback=11566 fixes=11566
[00:27] <lifeless> Ursinha: same logic for the tagger - can only deploy 11566 with the fix-for-11566, but humans would be confused by a rollback=11566
[00:27] <lifeless> Ursinha: lastly, we also need to be able to annotate this things after the fact: commit messags are nice, but we make mistakes.
[00:28] <Ursinha> lifeless, if we're reusing branches, I need to rely in commit messages
[00:28] <lifeless> Ursinha: that seems orthogonal to me.
[00:28] <Ursinha> for commit messages to be reliable, i.e. only contain valid in progress bugs, people all need to use ec2 land or bzr lp-land
[00:29] <mwhudson> wgrant: +edit and +admin look basically the same (?) and neither have nominatearchindep
[00:29] <Ursinha> lifeless, qa-tagger needs to consider something besides linked bugs to branches
[00:29] <lifeless> Ursinha: perhaps. We're iterating here, I recognise that.
[00:29] <lifeless> Ursinha: now that we have something working - and it is, cause we're deploying :P - we're finding out things that were not obvious up front
[00:30] <Ursinha> yes :)
[00:30] <Ursinha> that's nice
[00:30] <Ursinha> I was expecting that
[00:30] <lifeless> I've very excited and happy with what we've achieved so far.
[00:31] <Ursinha> lifeless, me too
[00:31] <Ursinha> lifeless, next step is to make html reliable and available, after that fix this problem of reused branches (that's messing with old bugs, argh)
[00:31] <wgrant> mwhudson: Maybe you'll need to set it with SQL.
[00:32] <mwhudson> wgrant: yeah, maybe
[00:32] <lifeless> Ursinha: part of the issue there is the many week delay between landing and deploy, as that gap narrows it will be easier.
[00:32] <wgrant> I'm boring and just use i386.
[00:32] <mwhudson> it wasn't the package i wanted to build though, so i don't really care
[00:32] <Ursinha> agreed
[00:32]  * mwhudson is building pyton2.6 so he can compare build times with the official builders
[00:33] <Ursinha> lifeless, what's the problem with 11566? that's an incremental qaable fix, right?
[00:33] <lifeless> Ursinha: thanks for interrupting your sprint; I think I'm good now, I know hat to look for for more revs
[00:33] <Ursinha> so the bug will be qa-needstesting
[00:34] <Ursinha> lifeless, it's late now, 8h40PM
[00:34] <Ursinha> I have to take matsubara-afk home :)
[00:34] <lifeless> Ursinha: no, the branch is broken
[00:34] <Ursinha> lifeless, is the bug qa-bad?
[00:34] <lifeless> Ursinha: if its rolled out without its second half it will break.
[00:34] <Ursinha> hm
[00:35] <lifeless> I put bad-revision-11566 in the bug tags
[00:35] <lifeless> Ursinha: 5 *6* 6 , not 5 *5* 6
[00:35] <Ursinha> lifeless, I know
[00:35] <lifeless> (I got confused between them yesterday :P)
[00:36] <Ursinha> lifeless, so it shouldn't be committed without the second part? why only half of the fix was committed?
[00:36] <Ursinha> lifeless, hehe
[00:36] <Ursinha> I almost did now :P
[00:36] <lifeless> Ursinha: it wasn't meant to be
[00:36] <lifeless> Ursinha: it was reviewed in two parts, meant to be landed in one.
[00:36] <lifeless> sorry bad-commit-11566
[00:36] <Ursinha> lifeless, right, so we should tell developers to don't do that
[00:36] <lifeless> hah
[00:36] <Ursinha> first of all
[00:37] <lifeless> yes, I agree its undesirable.
[00:37] <Ursinha> lifeless, I can't make the script work without some assumptions :)
[00:37] <Ursinha> or I'll spend 90% of the time trying to teach it how to workaround bad use of the process
[00:37] <Ursinha> but I understand it has to be considered
[00:38] <lifeless> agreed
[00:38] <Ursinha> so you think using the same mechanism of rollback tag should work
[00:38] <Ursinha> I agree
[00:38] <Ursinha> that would be nice exercise of the script, btw
[00:38] <lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
[00:39] <lifeless> Ursinha: I'd really like to see the other output from the script
[00:39] <lifeless> Ursinha: can you get it to go to the same file, or a different file?
[00:39] <lifeless> you know the stuff where it says what revs it looked at as it goes and so on. I know its not pretty, but its very helpful.
[00:39] <Ursinha> what's the other output? the html one?
[00:40] <lifeless> Ursinha: no, there were debug messages
[00:40] <Ursinha> ah
[00:40] <Ursinha> AH
[00:40] <Ursinha> I see
[00:40] <Ursinha> you want the true log
[00:40] <Ursinha> :)
[00:40] <lifeless> yes!
[00:40] <Ursinha> :)
[00:40] <Ursinha> debug log, cool
[00:40] <lifeless> wallyworld: thumper: https://bugs.edge.launchpad.net/launchpad-code/+bug/404131 needs QA
[00:40] <_mup_> Bug #404131: tales linkify create broken links  <qa-needstesting> <trivial> <ui> <Launchpad Bazaar Integration:Fix Committed by wallyworld> <https://launchpad.net/bugs/404131>
[00:41] <wallyworld> lifeless: ack
[00:56] <Ursinha> lifeless, https://devpad.canonical.com/~lpqateam/qa_reports/qa-tagger-stable.log
[00:57] <lifeless> Ursinha: \o/
[00:57] <Ursinha> :)
[00:57] <Ursinha> lifeless, should be there from now on
[00:57] <lifeless> Ursinha: thank you!
[00:58] <Ursinha> lifeless, my pleasure, sir :)
[00:58] <lifeless> now when 404131 is qa'd we should have another big batch CP'ing today
[00:58] <Ursinha> yay
[01:00] <poolie> hi, happy performance tuesday!
[01:01] <poolie> wallyworld: good question!
[01:05] <poolie> istr there's a way i can run process-mail.py feeding it from a test mailbox
[01:05] <poolie> to interactively test gpg/dkim stuff
[01:05] <poolie> is that true?
[01:06] <wgrant> lib/canonical/launchpad/doc/mailbox.txt
[01:10] <poolie> thanks
[01:58] <bdmurray> lifeless: I've received an ec2 failure regarding runJobHandleError and with a Fake exception.  Did you work on that last week or so?
[02:00] <lifeless> bdmurray: I changed some code in that area
[02:00] <lifeless> pastebin ?
[02:03] <bdmurray> https://pastebin.canonical.com/37437/
[02:03] <Ursinha> lifeless, hey
[02:04] <Ursinha> lifeless, thought about one workaround for 11566
[02:04] <Ursinha> lifeless, if we wait for the second branch to land, just leave it as qa-needstesting
[02:04] <Ursinha> when the second branch lands, it will mention the same bug, and it will be QAable
[02:04] <Ursinha> as soon as this bug gets then QAed ok, the first revision will be marked as ok to land
[02:04] <Ursinha> voila
[02:04] <lifeless> Ursinha: right, but we need to make sure that nothing lands without both.
[02:05] <Ursinha> the bugs ensures that
[02:05] <wgrant> Shouldn't the first branch just never land?
[02:05] <Ursinha> *bug
[02:05] <lifeless> Ursinha: how so ?
[02:05] <Ursinha> wgrant, land in qa environment
[02:05] <Ursinha> not production
[02:05] <lifeless> bdmurray: try with https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994 merged in
[02:05] <Ursinha> lifeless, the first and the second branches mention the same bug
[02:05] <wgrant> If the first branch is going to break things, it should never even hit devel alone, probably.
[02:06] <lifeless> Ursinha: yes, but a branch in the middle might be bad
[02:06] <Ursinha> wgrant, but it's only known as breaking things because it's already in the qa instance
[02:06] <Ursinha> lifeless, what do you mean?
[02:06] <wgrant> Ursinha: In 11566's case it was known that it would break things.
[02:06] <Ursinha> wgrant, so it shouldn't have landed in first place, but that happened and I don't know how to avoid that to happen again
[02:06] <lifeless> Ursinha: 11566=X, 11567=Y,11568=Z
[02:07] <lifeless> lets say that Z fixes X
[02:07] <lifeless> if we use a bug, as you say, then X and Z can be qa-ok on the same bug
[02:07] <lifeless> but Y may be qa-needstesting
[02:07] <Ursinha> lifeless, that's fine, but the special case of 11566 it's not bad, just incomplete
[02:07] <lifeless> if X is qa-ok then the rules say it can be deployed, but it can't, we have to deploy nothing, or X+Y+Z
[02:07] <Ursinha> both are part of the same bug fix
[02:07] <lifeless> Ursinha: its bad unless its complete.
[02:07] <lifeless> Ursinha: because it will break the buildmaster.
[02:08] <Ursinha> lifeless, but it will break anyway, because it will land in edge
[02:08] <Ursinha> that's the QA instance
[02:08] <lifeless> Ursinha: edge doesn't [yet] deploy to the buildmaster
[02:08] <Ursinha> ah
[02:08] <Ursinha> but that's not my point
[02:08] <lifeless> for qastaging, it would break yes.
[02:08] <Ursinha> that's the point
[02:08] <lifeless> or whatever tom is going to call the domain.
[02:09] <lifeless> as long as we do exercise soyuz there.
[02:09] <Ursinha> thing I want to say is that's not bad, but qa-needstesting that cannot be tested without the second part
[02:09] <Ursinha> or hm well
[02:10] <Ursinha> that's bad because it landed in the first place, so it should be rolled back...
[02:10] <lifeless> yes, but what if the rollback just contains the fix.
[02:10] <Ursinha> lifeless, in this special case the fix is the other part, right?
[02:10] <lifeless> from the deployment story its identical. X on its own = boom, X+Z together = ok.
[02:10] <lifeless> Ursinha: yes.
[02:10] <Ursinha> so keeping the branch qa-needstesting would block it from deployment, right?
[02:10] <Ursinha> branch no, bug
[02:10] <lifeless> as will bad-commit-xxxxxx
[02:11] <Ursinha> but why use that
[02:11] <lifeless> which I think is accurate.
[02:11] <lifeless> because it is a bad commit, all commits are -meant- to keep trunk stable
[02:11] <Ursinha> it's because it's not just a partial fix, but it's breaking stuff?
[02:11] <lifeless> right
[02:11] <Ursinha> I see
[02:11] <lifeless> its not incremental
[02:11] <lifeless> its damaged without its soul mate
[02:12] <Ursinha> it's bad
[02:12] <Ursinha> nothing much special about it, just bad
[02:12] <Ursinha> break stuff, should not be there
[02:12] <lifeless> I'm proposing a pqm commit messag elike fixcommit=12345 to handle roll-forward rathr than rollback
[02:12] <lifeless> Ursinha: yes, it shouldn't have happened, but we need to deal when it does
[02:13] <lifeless> the only difference fixcommit and rollback would have is:
[02:13] <Ursinha> lifeless, I'm thinking out loud to check if I make sense
[02:13] <lifeless> rollback tags in-progress again, fixcommit doesn't change the bug 'status' field.
[02:13] <Ursinha> hm
[02:15] <Ursinha> so we'd need to say that it not just is a rollback but a fix itself
[02:15] <lifeless> yes
[02:23] <wgrant> mwhudson: How's python2.6 going?
[02:25] <mwhudson> wgrant: it seems to be running the tests
[02:25] <wgrant> Aha.
[02:25] <mwhudson> https://edge.launchpad.net/ubuntu/+source/python2.6/2.6.6-5ubuntu1/+build/1961090 -> (took 3 hours, 35 minutes, 1.1 seconds)
[02:25] <mwhudson> been going for close to 2 on my board, so a while yet, i expect
[02:28] <wgrant> Hm, the xM looks rather nice.
[02:28] <mwhudson> wgrant: o
[02:28] <mwhudson> bah
[02:29] <mwhudson> wgrant: i've been blogging about it! http://voices.canonical.com/michael.hudson/
[02:31] <wgrant> I may have to acquire one. My previous ARM board is now acting as the home servery/routery thing, so I need something to experiment on.
[02:45] <lifeless> anyone know the status of 'mentoring'
[02:46] <mwhudson> lifeless: i think it's "kill code on sight", not 100% sure though
[02:47] <wgrant> "Under trial withdrawal" is the official status.
[02:47] <wgrant> Removed from the UI and condemned, but code not yet deleted.
[02:49] <wgrant> Although the reference to it in the feature listing seems to have now been entirely removed.
[02:53] <lifeless> and it causes extra queries.
[02:53] <lifeless> le sigh
[02:54] <lifeless> thumper: I think its better to do this via a garbo patch:
[02:54] <lifeless>  - gets rid of the interrupt on spm
[02:54] <lifeless>  - long term solution
[02:54] <thumper> lifeless: yes, so you have said multiple times already
[02:54] <lifeless>  - same basic code as we'd be cowboying, but tested
[02:54] <thumper> and it will be
[02:55] <lifeless> thumper: I've been thinking more about it
[02:55] <lifeless> thumper: that was summary; nuff said.
[02:55] <lifeless> oh, and man echannel too.
[02:55]  * lifeless hides in shame
[02:56] <spm> chuckles
[03:31]  * thumper code dives
[03:32] <lifeless> zomg
[03:32] <lifeless> the celebrity code queries every time ...
[03:33] <wgrant> I thought it cached IDs.
[03:33] <wgrant> That's how you can get MutatedCelebrityErrors.
[03:33] <lifeless> now when you do ).admin
[03:34] <lifeless> or perhaps my test is just catching the cache loading
[03:34] <lifeless> still
[03:34] <lifeless> ECRY
[03:34] <wgrant> It will have to load the object if it's not in the cache.
[03:34] <wgrant> But I believe it's meant to cache the ID over transactions.
[03:53] <Ursinha> lifeless, https://devpad.canonical.com/~lpqateam/qa_reports/logs/
[03:53] <Ursinha> I've changed them all to a separate folder
[03:58] <lifeless> thanks for letting me know
[04:00] <wgrant> I wonder how badly LP breaks on pg 9.0.
[04:09] <lifeless> mwhudson: LaunchBag is spectacularly ugly
[04:09] <mwhudson> lifeless: yes
[04:28] <lifeless> silly question
[04:28] <lifeless> is it ok to have __init__ on SQLBase classes
[04:28] <lifeless> or .. ah _init?
[04:35] <Ursinha> I'm done for today
[04:40] <Ursinha-zzz> lifeless, could you please file a bug for the fixes-xxxxx problem?
[04:43] <lifeless> Ursinha-zzz: go sleep
[04:43] <lifeless> :)
[04:51]  * thumper goes offline briefly while IRC proxy goes to maverick
[04:55] <lifeless> I'm making progress
[04:55] <lifeless> viewing a single bug page with no subscribers is now down to 99 queries.
[04:56] <lifeless> !
[04:56] <poolie> from where?
[04:56] <lifeless> 110 when I started this branch
[04:56] <wgrant> lifeless: How many comments/tasks?
[04:56] <lifeless> wgrant: 1/1
[04:57] <wgrant> ..... ew.
[04:57] <lifeless> wgrant: I took my view scaling test (14 queries), made it render...
[04:57] <lifeless> and blinked.
[05:00] <poolie> i was thinking this morning about the idea of giving sql planner logs back to the client
[05:00] <poolie> and it occurred to me that giving them to the web app (to put in an oops) would be nice but isn't strictly necessary
[05:00] <poolie> *if* it turns out that logging them is not noticeably expensive, perhaps we could log them all the time and just make them available on devpad
[05:01] <lifeless> we have detailed logging off on the master due to load.
[05:02] <poolie> it does show up?
[05:02] <lifeless> Have I done the numbers myself ? no. Ask stub :P
[05:02] <lifeless> I presume its turned off because someone measured.
[05:02] <poolie> i believe you, i'm just curious
[05:03] <poolie> just thought it would be nice to cut out the roundtrips to get this
[05:03] <lifeless> anyhow, I'd expect query plan serialisation to be similar overhead: totally fine from time to time but significant if on all the time
[05:03] <lifeless> poolie: personally, ignoring performance, I'd rather have it in the oops.
[05:03] <lifeless> nicely interleaved with the queries.
[05:03] <lifeless> rather than in a separate file i have to go read
[05:03] <poolie> i agree
[05:03] <poolie> i was just thinking it would be less work to record it to a log
[05:04] <lifeless> have a look at requesttimeline
[05:04] <lifeless> its nice
[05:04] <lifeless> shove it in there, it turns up in the oops, bada boom bada bing
[05:04] <poolie> where is it?
[05:04] <lifeless> lp.services.timeline
[05:06] <poolie> ok, thanks
[05:06] <lifeless> hmm, we query the tags for the js fragment twice... sigh
[05:07] <lifeless> no, something else
[05:13] <poolie> wgrant: if you're free could you do a security-oriented review of https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985
[05:14] <lifeless> nah, he charges ;P
[05:15] <poolie> lifeless: could you please land https://code.edge.launchpad.net/~mbp/launchpad/flags-webapp/+merge/32967 for me
[05:15] <wgrant> Let's see.
[05:18] <wgrant> +            canonicalise_line_endings(mail.signedContent), signature)
[05:18] <wgrant> WTF
[05:18] <wgrant> mixedCase attributes?
[05:18] <wgrant> Must be old code.
[05:18] <poolie> not my fault
[05:18] <wgrant> I know.
[05:18] <wgrant> Makes me cringe anyway :)
[05:19] <poolie> what is the standard meant to be? underscored attributes, camelcase methods?
[05:19] <wgrant> Right.
[05:19] <wgrant> PEP-8 with a pinch of Zope.
[05:20] <poolie> urk
[05:20] <poolie> biab
[05:27] <lifeless> is bugtask.distribution always set when bugtask.sourcepackagename is ?
[05:27] <lifeless> hmm
[05:27] <wgrant> I hope so.
[05:28] <lifeless> actually
[05:28] <lifeless> it never is
[05:28]  * lifeless suspect official bug tag adaption mojo
[05:28] <wgrant> Er.
[05:29] <wgrant> What?
[05:29] <wgrant> sourcepackagename on its own is useless.
[05:29] <wgrant> distribution and distroseries should be mutually exclusive.
[05:29] <wgrant> But sourcepackagename should always have one of those two, although it's not enforced by the DB.
[05:29] <lifeless> it is
[05:29] <lifeless> CONSTRAINT bugtask_assignment_checks
[05:30] <wgrant> Ah, true.
[05:43] <thumper> AssertionError: not equal:
[05:43] <thumper> a = set([u'revision-id319180', u'revision-id319182', u'revision-id319184', u'revision-id319186', u'revision-id319188', u'revision-id319198', u'revision-id319196', u'revision-id319194', u'revision-id319192', u'revision-id319190'])
[05:43] <thumper> b = set([u'revision-id319180', u'revision-id319182', u'revision-id319184', u'revision-id319186', u'revision-id319188', u'revision-id319198', u'revision-id319196', u'revision-id319194', u'revision-id319192', u'revision-id319190'])
[05:43] <thumper> is it me or is that crackful?
[05:44] <lifeless> are those actually strings or storm objects with pretty reprs?
[05:45] <thumper> lifeless: good point
[05:45]  * thumper double-checks
[05:45] <wgrant> s/pretty/shocking/
[05:46] <thumper> it says unicode
[05:47] <wgrant> It's not assertIs?
[05:47] <thumper> assertEqual
[05:47] <wgrant> Bah.
[05:47] <lifeless> wgrant: != - assertEqual in testtools prints out like that
[05:48] <lifeless> thumper: yes, thats cracked.
[05:48] <thumper> a == b in the python interpreter
[05:48] <stub> So the repr is bogus
[05:49] <mwhudson> woo python2.6 built on the beagle xm
[05:49] <mwhudson> took 4 hours, 53 minutes, 23.1 seconds
[05:49] <mwhudson> so a bit slower than the official buildd
[05:49] <wgrant> So not too slow.
[05:49] <mwhudson> not too shabby though
[05:50] <mwhudson> given that you can buy xm's by the crate now
[05:50] <wgrant> Is the buildd hardware publicly available yet?
[05:50] <wgrant> mwhudson: They're actually on backorder pretty much everywhere.
[05:50] <mwhudson> you mean, the details of what it is?
[05:50] <wgrant> But yes.
[05:50] <wgrant> No, the actual devices.
[05:50] <wgrant> For a while the buildds were unreleased hardware.
[05:50] <thumper> lifeless: http://pastebin.ubuntu.com/497480/
[05:50] <thumper> lifeless: I'm in the pdb session
[05:50] <mwhudson> wgrant: ok, well linaro has about 40 or something now
[05:51] <mwhudson> maybe not that many
[05:51] <mwhudson> but >10 anyway
[05:52] <mwhudson> wgrant: eh, the buildds are some kind of fancy dev board i think, i'm not sure that it's ever going to be publicly available in the sense of being able to just pony up a credit card number and buy one
[05:52] <mwhudson> icbw though
[05:53] <mwhudson> thumper: wth!
[05:53] <mwhudson> (Pdb) print list(expected) == list(observed)
[05:53] <mwhudson> True
[05:53] <mwhudson> (Pdb) expected == observed
[05:53] <mwhudson> False
[05:53] <mwhudson> thumper: types of the set classes?
[05:53] <mwhudson> print type(expected) == type(observed)
[05:53] <lifeless> one of these is not like the other
[05:54] <wgrant> Maybe it's security proxied.
[05:54] <wgrant> But that should normally be fine.
[05:54] <wgrant> Unless set has some horrible optimisation.
[05:54]  * wgrant throws Django's URL system into the "cruel joke" bin.
[05:55] <mwhudson> if observed is proxied, i bet observed == expected would be true
[05:55] <thumper> (Pdb) print type(expected) == type(observed)
[05:55] <thumper> True
[05:55] <wgrant> ...
[05:56] <lifeless> print type(expected), type(observed)
[05:56] <wgrant> Are they both actually sets?
[05:56] <wgrant> That.
[05:56] <mwhudson> ok
[05:56] <mwhudson> starting to think weird ass bugs now
[05:56] <thumper> fucking proxies
[05:56] <mwhudson> ah
[05:56] <wgrant> They're both proxied?
[05:56]  * lifeless chalks another one up to 'lets remove the proxies'
[05:57] <stub> That shouldn't mess with == :-/
[05:57] <thumper> yes, both proxies
[05:57] <thumper> stub: they are both proxied sets
[05:58] <stub> Yes, but the wrappers are supposed to be transparent to pretty much everything (everything but 'is' / 'is not' IIRC)
[05:59] <thumper> stub: probably the testtools implementation of assertEquals
[05:59] <lifeless> rockstar: you forgot the link
[05:59] <wgrant> No, == says they're not equal.
[06:00] <wgrant> It's nothing to do with testtools.
[06:01] <thumper> wgrant: good point
[06:02] <wgrant>     def __eq__(self, other):
[06:02] <wgrant>         if isinstance(other, BaseSet):
[06:02] <wgrant>             return self._data == other._data
[06:02] <wgrant>         else:
[06:02] <wgrant>             return False
[06:03] <wgrant> But surely the proxies are smarter than that.
[06:04] <rockstar> lifeless, ?
[06:05] <mwhudson> wgrant: return **False** !
[06:05] <mwhudson> surely that should be NotImplemented
[06:05] <mwhudson> unless comparison is different
[06:05] <wgrant> Hm. Except that's sets.Set, which is not set.
[06:05] <wgrant> Now, where is set...
[06:06] <mwhudson> wgrant: Modules/setsmodule.c
[06:06] <wgrant> Oh.
[06:06] <rockstar> lifeless, ah, I see.
[06:06]  * rockstar _should_ go to bed.
[06:06] <wgrant> I was looking at setobject
[06:06] <wgrant> mwhudson: I have no setsmodule.c
[06:07] <mwhudson> oh right
[06:07] <mwhudson> yes setobject
[06:07] <mwhudson> sorry
[06:09] <lifeless> grah
[06:09] <lifeless> so, if I've added an attribute to the Interface
[06:09] <lifeless> how do I specify access permissions for it ?
[06:09] <thumper> lifeless: it depends
[06:09] <lifeless> ForbiddenAttribute: ('official_tags', <Bug at 0xef872d0>)
[06:09] <thumper> lifeless: on how the interface itself has the permissions set
[06:09] <wgrant> mwhudson: Looks like it has the same bug as the Python one.
[06:10] <lifeless> official_tags = Attribute("The official bug tags relevant to this bug.")
[06:10] <wgrant> It does the type check and returns false, rather than NotImplemented like makes sense, and others seems to do.
[06:12] <wgrant> lifeless: Bug doesn't use interfaces for security.
[06:12] <wgrant> It lists the attributes in ZCML.
[06:12] <lifeless> siiiiiiigh
[06:12] <thumper> lifeless: lib/lp/bugs/configure.zcml line 574ish
[06:12] <thumper> lifeless: also that file has lots of references to canonical.launchpad.database.*
[06:12] <thumper> lifeless: which it shouldn't
[06:13] <lifeless> thats so bong
[06:13] <wgrant> sinzui: Why are maps dying?
[06:13]  * thumper rings lifeless's bong
[06:13] <thumper> wgrant: cost is one reason
[06:13] <lifeless> wgrant: they want lots of money to serve on ssl
[06:13] <thumper> wgrant: and they changed the api
[06:13] <wgrant> Yay.
[06:13] <lifeless> thumper: to be fair, thats orthogonal
[06:14] <lifeless> the primary problem was our account expired.
[06:14] <thumper> yeah, it is
[06:15] <lifeless> ohhhh
[06:15] <lifeless> TypeError: [] is not JSON serializable
[06:15] <wgrant> Um.
[06:15]  * lifeless is not sure if a practical joke is being played or not
[06:15] <wgrant> What?
[06:15] <lifeless> ooooh
[06:16] <lifeless> I bet I know
[06:16] <wgrant> Proxies?
[06:16] <lifeless> the list is security proxied
[06:16] <wgrant> Heh.
[06:16] <lifeless> so the browser code which was doing a redundant sorted(list( <- and yes thats also self redundant
[06:16] <lifeless> was hiding that
[06:16] <wgrant> Is this still BugTask:+index?
[06:16] <lifeless> yes
[06:16] <lifeless> will save, about 40 queries on bug 1
[06:17] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
[06:17] <lifeless> its got waay to many bugtasks.
[06:17] <poolie> wgrant: any other comments on that patch?
[06:17] <wgrant> poolie: That getUtility(ILaunchpadBag).to_user looks like a sed gone wrong.
[06:17] <lifeless> yay, finally, squashed that one.
[06:17] <mwhudson> lifeless: work on deleting a bug task next? :-)
[06:17] <poolie> i could make it more testable by tearing apart the methods more
[06:18] <lifeless> mwhudson: nah, I'm going to defeat this foul beast.
[06:18] <poolie> but i anticipate an uncomfortable interval where the patch gets bigger but the tests don't get safer
[06:18] <lifeless> of course, the patch is going to be a) ugly and b) insufficiently tested.
[06:18] <lifeless> But
[06:18] <wgrant> poolie: Apart from that it looks OK. But the code needs refactoring.
[06:18] <lifeless> It has the only test I care about right now: query scaling :)
[06:19] <poolie> ah you're right about the '.to_user' well spotted
[06:20] <poolie> i think my next refactoring would be to separate "determine who this comes from and how strongly they're trusted" from "become that user"
[06:20] <poolie> cleaner to test that way i think
[06:21] <wgrant> poolie: That suggests a missing test.
[06:21] <wgrant> Or you just didn't find it.
[06:21] <poolie> it does, doesn't it
[06:21] <wgrant> Hm.
[06:21] <lifeless> is there a debug mode to tal?
[06:21] <wgrant> I wonder if the LP favicon should be that of the current context.
[06:21] <poolie> i didn't run everything but i ran 'bin/test mail' which you'd think would catch it
[06:21] <lifeless> that is, to print the thing being evaluated?
[06:21] <lifeless> or similar
[06:22] <poolie> i think it is a missing test and i could add one
[06:22] <poolie> and see if it would have trapped on that line
[06:53] <lifeless> down to 88
[06:53] <poolie> lifeless, wgrant, how about something like http://pastebin.ubuntu.com/497509/ as a test?
[06:55] <lifeless> seems fine to me; lines 8,9 and 10 look like they will want to be reusable
[06:56] <poolie> mm
[07:01] <poolie> a lot of it should be
[07:05] <wgrant> maxb: Is python-debian really still needed in the PPA? It's in sourcecode now.
[07:09] <poolie> wgrant i'm pretty sure there was no test for mail to help@ but there is one now
[07:09] <wgrant> poolie: Great.
[07:16] <poolie> can you two help me decide whether to add more tests to this or just leave it?
[07:17] <poolie> i don't want to break incoming mail but i also want to leave this and work on something else
[07:21] <lifeless> poolie: how big is the change? is it flag controllable? that would make it easy to back out.
[07:21] <poolie> it's https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985
[07:21] <lifeless> poolie: For refactoring I tend to remove all but one old-place test, and move them to the new place, and not try to add coverage
[07:22] <poolie> it's not flag controllable atm and it's refactoring code that seems poorly tested at the moment
[07:22] <poolie> thus my discomfort
[07:22] <wgrant> It's also rather ancient code.
[07:23] <lifeless> poolie: do you think it needs more tests?
[07:23] <poolie> in general, yes, it does
[07:23] <poolie> does it need me to add them right now? i hope not :)
[07:23] <lifeless> poolie: to be comfortable landing this change I mean?
[07:25] <poolie> i don't know
[07:26] <poolie> i have a sinking feeling that to be able to test it more i'll have to change more stuff
[07:26] <lifeless> so
[07:26] <lifeless> stop
[07:26] <lifeless> land it, qa on staging, rather than edge, done.
[07:26] <poolie> in particular, to make it have less side effects
[07:27] <poolie> fair enough
[07:27] <poolie> staging receives mail, even thought it doesn't send it?
[07:27] <poolie> and we can now see the mail logs from it, or we should be able to
[07:34] <lifeless> it should be able to yes
[07:34] <lifeless> if not, I'll RT that :P
[07:38] <poolie> i replied to the rt asking for logs from staging too
[07:39] <poolie> they don't seem to be visible atm
[07:41] <lifeless> 84
[07:42] <poolie> ok, so with that off the plate i'll look at a flags editor
[07:45] <lifeless> \o/
[07:45] <lifeless> you wanted a chat with wallyworld
[07:45] <lifeless> I'm up for that nowish
[07:45] <poolie> is he?
[07:45] <poolie> <hold music>
[07:46] <wallyworld> dah de dah dah de dah
[07:46] <poolie> wallyworld, lifeless: mumble/skype/pots?
[07:46] <wallyworld> skype is ok for me
[07:47] <wallyworld> i don't have any specific agenda
[07:47] <wallyworld> some of my random musings have already been aired in the mailing list
[07:47] <lifeless> poolie: skype plox
[07:54] <lifeless> 76
[09:01] <lifeless> 74
[09:01] <wgrant> It's a countdown!
[09:01] <wgrant> But to what?
[09:04] <lifeless> sob
[09:05] <lifeless> return list(MilestoneVocabulary(self.context)) != []
[09:05] <wgrant> Bwahah.
[09:05] <wgrant> At least it is scoped.
[09:06] <lifeless> guess how many milestones bug 1 has
[09:06] <lifeless> ...
[09:06] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
[09:06] <wgrant> Why's it doing that? To work out whether to display the milestone selector?
[09:08] <lifeless> wgrant: yes
[09:08] <wgrant> Yay.
[09:08] <lifeless> browser/bugtask.py 3632
[09:09] <bigjools> jeez, someone added 200 builds this morning
[09:09] <lifeless> buildds?
[09:10] <wgrant> jml: Are you going to get that BuilderSlave.clean thing merged?
[09:10] <bigjools> https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20100920/20100922/
[09:10] <jml> doo-di-dee-dooo, doo-di-dee-do, doo-di-dee-dooo, doo-di-dee-do-do-di, doo-do-de-doo doo-de-de-do-do-do-do-dooo...
[09:10] <jml> IT's THE FINAL COUNTDOWN!
[09:10] <bigjools> THE FINAL SOL^WCOUNTDOWN
[09:11] <adeuring> good morning
[09:12] <jml> wgrant, yes, I'm going to do that next thing.
[09:12] <wgrant> lifeless: My religion forbids me from opening a file that large.
[09:13] <wgrant> jml: Great, thanks. Everything seems to work well with that fixed.
[09:14] <bigjools> wgrant: bug 644059
[09:14] <_mup_> Bug #644059: buildd upload processor explodes if source produced by binary build <Soyuz:New> <https://launchpad.net/bugs/644059>
[09:14] <bigjools> can you write that in English? :)
[09:15] <wgrant> bigjools: Description updated.
[09:15] <bigjools> grassy ass
[09:15] <wgrant> Heh.
[09:16] <jml> wgrant, how did mwhudson trigger the bug in first place? it would be nice to have some kind of test for that.
[09:16] <jml> as well as a direct one for clean.
[09:16] <wgrant> jml: I triggered it too.
[09:16] <wgrant> Let me check my logs.
[09:16] <jml> no matter
[09:16] <jml> bigjools has just given me a few pointers
[09:16] <jml> mrevell, hello
[09:17] <bigjools> wgrant: was it getting called from rescueBuilderIfLost ?
[09:17] <wgrant> bigjools: No, updateBuild.
[09:18] <bigjools> ok
[09:18] <wgrant> Although rescueBuilderIfLost probably had the same issue.
[09:18] <mrevell> Hello
[09:18] <bigjools> yes
[09:18] <bigjools> hey mrevell
[09:18] <wgrant> We also sometimes get into a situation where a BuilderSlave is used during dispatch to.
[09:18] <wgrant> NFI how.
[09:19] <jml> if all goes well, that won't matter at the end of the week.
[09:20] <wgrant> Indeed.
[09:22] <wgrant> Although I wonder how much of a performance boost it will be.
[09:22] <jml> I would like someone to review this please: https://code.edge.launchpad.net/~jml/launchpad/split-mail-and-summary/+merge/36111
[09:23] <jml> wgrant, probably not much.
[09:23] <jml> wgrant, the sanity boost is not to be sneezed at
[09:23] <wgrant> That's true.
[09:30] <jml> bigjools, you might be interested in this bug: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/419685
[09:30] <_mup_> Bug #419685: Buildbot sends emails that require no action <build-infrastructure> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/419685>
[09:36] <lifeless> sigh
[09:36] <lifeless> the per row stuff here is still going to be terrible.
[09:41] <jml> It's such a good branch.
[09:43] <lifeless> jml: ask me how many queries viewing a trivial bug page with no subscribers, 2 product tasks takes.
[09:44] <jml> lifeless, I've been wondering, ...
[09:44] <lifeless> 110
[09:44] <jml> lifeless, :(
[09:44] <lifeless> jml: I got pissed off enough this morning
[09:44] <lifeless> that I'm doing something about it
[09:44] <lifeless> I'm down to 72
[09:45] <jml> lifeless, woot!
[09:45] <lifeless> 1 15 files changed, 157 insertions(+), 86 deletions(-)
[09:45] <jml> !
[09:45] <lifeless> jml: I may want a very pragmatic review for this :P
[09:45] <jml> lifeless, ok. :)
[09:45] <jml> lifeless, swap you.
[09:45] <lifeless> sure, what up
[09:45] <jml> https://code.edge.launchpad.net/~jml/launchpad/split-mail-and-summary/+merge/36111
[09:45] <jml> better mail from ec2
[09:46] <StevenK> \o/
[09:49] <lifeless> done
[09:54] <lifeless> 68
[09:56] <jml> lifeless, thanks.
[09:56] <jml> (also, wuuu)
[09:56] <wgrant> lifeless: I suppose it also now scales better?
[09:57] <bigjools> have you seen how many HTTP requests there are for a bug page with a cold browser cache?
[09:58] <wgrant> What are they all?
[09:58] <wgrant> I can't think of too many.
[09:58] <bigjools> try it in .dev
[09:58] <wgrant> .dev is special.
[09:58] <wgrant> The JS isn't merged, is it?
[10:01] <bigjools> ummm I dunno
[10:01] <bigjools> anyway
[10:01]  * bigjools -> sprint
[10:02] <lifeless> wgrant: somewhat
[10:02] <lifeless> wgrant: I haven't reached the last query yet.
[10:02] <lifeless> it will still do 4 queries per nomination.
[10:02] <wgrant> :(
[10:02] <wgrant> lifeless: Was your mass-CP rolled out everywhere?
[10:03] <wgrant> Even Soyuz?
[10:04] <lifeless> checkwatches + appservers
[10:04] <lifeless> not quite everywhere
[10:04] <lifeless> AIUI
[10:04] <lifeless> there was a singular CP done at the same time
[10:05] <wgrant> Looks like it did make it to cocoplum anyway.
[10:05]  * lifeless headdesks
[10:05] <lifeless> SELECT COUNT(*) FROM Bug WHERE Bug.duplicateof = %s
[10:05] <wgrant> Hmm?
[10:05] <bigjools> ummm that's bad if you updated cocoplum
[10:05] <wgrant> bigjools: Why?
[10:05] <wgrant> The buildd-manager thing wasn't in the last batch.
[10:05] <bigjools> if the b-m change made it there
[10:05] <bigjools> ah ok
[10:05] <bigjools> *phew*
[10:06] <wgrant> And b-m is OK now, anyway.
[10:06] <bigjools> well no, it needs a cronjob
[10:06] <wgrant> Just needs the extra cron job set up before the next CP.
[10:06] <wgrant> Right.
[10:06] <lifeless> wgrant: we have a denormalised field to avoid that particular query
[10:06] <lifeless> wgrant: ...
[10:07] <wgrant> Hah, so we do.
[10:07] <wgrant> It shouldn't be too slow, though.
[10:08] <lifeless> wgrant: hah
[10:08] <lifeless> wgrant: hah
[10:08] <lifeless> wgrant: hah
[10:08] <wgrant> Really?
[10:08] <lifeless> count(*) is one of the slower operations you can do
[10:08] <wgrant> No bug ever has more than a few hundred.
[10:09] <wgrant> So there's not a huge number of rows to go through.
[10:09] <lifeless> wgrant: right, but it still requires a index operation that is not significantly cheaper than select..
[10:10] <wgrant> Yeah.
[10:10] <lifeless> AND WE HAVE THE NUMBER RIGHT THERE.
[10:10] <lifeless> (emphasis mine)
[10:12] <lifeless> 66
[10:13] <lifeless> wgrant: hey, guess how bug privacy duplicates interact
[10:17] <wgrant> Badly?
[10:18] <lifeless> well, and I'm just guess
[10:18] <lifeless> ing
[10:18] <lifeless> one query per private dupe
[10:18] <lifeless> maybe 2
[10:19] <wgrant> Only 1?
[10:19] <wgrant> Yeah...
[10:19] <lifeless> guess what happens when apport backlogs

[10:20] <jml> have those windmill failures been addressed?
[10:24] <lifeless> not that I know of
[10:24] <lifeless> mars says he's oging to look at bb soon
[10:24] <lifeless> also \u/ for duplicate methods that do exactly the same thing
[10:25] <lifeless> personIsDirectSubscriber == isSubscribed
[10:25] <lifeless> 64
[10:27] <jml> lifeless, hey, your fixture thing is an lp dep?
[10:31] <lifeless> jml: yes
[10:32] <jml> lifeless, ok. should we deprecate the lp.testing.fixtures business?
[10:32] <lifeless> jml: its mostly moved over to context managers already; I moved fakelibrarian
[10:32] <lifeless> there's one use remaining I think.
[10:32] <jml> lifeless, looking at lp.testing.fixtures, it's not using ctxmgrs at all
[10:33] <lifeless> I may be confused. ELate+BugTask:+index is consuming me
[10:33] <lifeless> 63
[10:35] <wgrant> 8 to go!
[10:35] <jml> lifeless, fixtures... sourcedeps, package or eggs?
[10:36] <jml> (cos it ain't working)
[10:36] <lifeless> jml: its in the dist-cache
[10:36] <jml> dist-cache
[10:36] <lifeless> jml: versions.cfg etc
[10:36] <lifeless> downloadcache/dists
[10:36] <jml> ahh, thanks.
[10:36] <lifeless> jml: works for me; check the fake librarian
[10:36] <lifeless> you may have an old  branch?
[10:37] <jml> lifeless, I don't see *anything* that imports 'fixtures'
[10:38] <jml> lifeless, the branch is current as of Monday morning.
[10:38] <lifeless> lib/lp/testing/fakelibrarian.py
[10:38] <lifeless> line 22
[10:38] <lifeless>  16 files changed, 197 insertions(+), 122 deletions(-)
[10:39] <jml> lifeless, thanks. merging in latest stable gets it.
[10:42] <lifeless> jml: https://code.edge.launchpad.net/~lifeless/launchpad/bugtask+index/+merge/36117
[10:42] <lifeless> noodles775: ping
[10:42] <noodles775> Hi lifeless
[10:42] <lifeless> hiya
[10:43] <lifeless> so you've got a branch called 'expose distro diff' or thereabouts
[10:43] <noodles775> YEs
[10:43] <lifeless> I wanted to check that you're happy for that to happen on lpnet, *now* (in principle)
[10:43] <lifeless> and that you're not basing it on 'this release cycle'
[10:43] <noodles775> erm, It's for db-devel?
[10:43] <lifeless> noodles775: ah, I didn't see that :P
[10:44] <noodles775> I mighht not have set it...
[10:44] <lifeless> safe enough then (though personally I'd still use a flag, in case you find a bug at the last minute or post release and want to pull the feature)
[10:44] <wgrant> Is the API flaggable?
[10:44] <lifeless> should be
[10:45] <lifeless> same request object IIRC
[10:45] <lifeless> you can't change whats exported
[10:45] <wgrant> True.
[10:45] <noodles775> I've flagged the UI, but didn't see it as necessary to flag the API for it (since there will not be any data to access).
[10:45] <lifeless> but you can control what it does
[10:45] <lifeless> I would't stress about the API
[10:45] <wgrant> I still don't see how the current derivation model can work.
[10:45] <wgrant> But I guess we'll see.
[10:45] <noodles775> wgrant: in what way?
[10:46] <wgrant> noodles775: We need multiple parents.
[10:46] <lifeless> jml: I got that branch exactly the right size it seems (800 lines)
[10:46] <wgrant> Changing parent_series after initialisation will break a few things and seems a bit ew.
[10:46] <noodles775> wgrant: ah, right. AFAIK multiple parents was discussed by bigjools-afk with others, but not included in the initial release. I don't know the details.
[10:50] <lifeless> jml: its getting late, so I'd like to know if you're going to look now, or later.
[10:50] <jml> lifeless, am looking now
[10:52] <jml> lifeless, is MilestoneTarget.has_milestone a property?
[10:52] <lifeless> yes
[10:52] <jml> ta
[10:52] <lifeless> if you mean has_milestones
[10:53] <lifeless> its about a brazillion times faster than the vocab
[10:56] <jml> lifeless, yeah.
[10:56] <jml> lifeless, I've approved modulo some clarity/style tweaks.
[10:56] <jml> lifeless, great patch. thanks.
[10:56] <lifeless> thanks
[11:03] <noodles775> Has anyone seen "psycopg2.ProgrammingError: server closed the connection unexpectedly" when running `make schema`? http://pastebin.ubuntu.com/497604/
[11:04] <lifeless> jml: dumps(security_proxied_list) goes boom
[11:04] <lifeless> jml: thats why the comment; I've expanded it.
[11:04] <jml> lifeless, thanks.
[11:04] <wgrant> noodles775: I haven't seen that. Does the postgres log say anything useful?
[11:05] <lifeless> jml: also I mean 'tp' query - 'tp = ' is 4 lines up.
[11:05] <noodles775> wgrant: yes - I should have checked there first. FATAL:  the database system is in recovery mode
[11:05] <wgrant> Aha.
[11:05] <jml> lifeless, heh. ok.
[11:05] <lifeless> noodles775: nuke your db
[11:06] <lifeless> noodles775: and start over; its the easiest way
[11:06] <noodles775> k, thanks lifeless, wgrant
[11:24] <lifeless> gmb: did you talk to the mozilla folk
[11:26] <gmb> lifeless, Can you be more specific? I might have missed something whilst sifting through my mail pile yesterday
[11:27] <gmb> lifeless, Ah
[11:27] <gmb> https://bugs.edge.launchpad.net/malone/+bug/642418 you mean?
[11:28] <_mup_> Bug #642418: Detect when remote Bugzilla bugs are duplicates and link to the duped-to bug instead <Launchpad Bugs:New> <https://launchpad.net/bugs/642418>
[11:28] <gmb> lifeless, Exactly to whom should I be talking and what needs to be said?
[11:29] <lifeless> $folk and $mozilla that are $concerned
[11:29] <lifeless> I dunno
[11:29] <gmb> lifeless, That's $unhelpful.
[11:30] <lifeless> I just got told you knew all about this stuff :)
[11:30] <lifeless> so I helpfully palmed the enquirers off with yourname and a glib assertion that you'd be helpful/
[11:30] <gmb> Haha.
[11:30] <lifeless> poolie: would appreciate any insight you have into https://bugs.edge.launchpad.net/launchpad-foundations/+bug/634342
[11:30] <gmb> Helpful doesn't start until this afternoon.
[11:30] <_mup_> Bug #634342: need a features 'scope' for page ids <qa-ok> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/634342>
[11:30] <gmb> lifeless, I know the code, at least. Let me dig further into this. I'll add it to my todo list for today.
[12:00] <deryck> Morning, all.
[12:18] <lifeless> hmm, clearly I'm up too late.
[12:19] <spiv> lifeless: yes
[12:27] <lifeless> gary_poster: you're around now, I take it ?
[12:27] <gary_poster> lifeless, yes on call but what are you doing up?!
[12:28] <lifeless> well, I had a itsy bitsy morning
[12:28] <lifeless> and then I got my teeth into BugTask:+index
[12:28] <lifeless> still winding down from that ;)
[12:29] <lifeless> gary_poster: when do you think you'll be off the call?
[12:29] <gary_poster> 10 min?
[12:29] <lifeless> hmmm, if you're up for a catch up post that, I might hang about a little more
[12:34] <gary_poster> lifeless, you are crazy, but I am off the call and available for ~20 min.  mumble, irc, skype...?
[12:34] <lifeless> like a fox
[12:34] <gary_poster> :-)
[12:34] <lifeless> lets say skype
[12:35] <gary_poster> ok
[12:35] <lifeless> rbtcollins
[12:36] <wgrant> We really need to work out a better bug notification strategy.
[12:37] <wgrant> Since my top timeout is probably mostly that :(
[12:37] <deryck> wgrant, completely agree
[12:37] <wgrant> I wonder if it's as easy as removing BugNotificationRecipient and calculating it when we send them.
[12:37] <wgrant> Or if that will miss some things (like bugs being reassigned)
[12:39] <deryck> I think it could be more complex than that, but it's an easy check to remove it and run tests to see what breaks.
[12:45] <wgrant> Yeah, it's not that simple, sadly.
[12:45] <wgrant> Since the recipients can change if the task target does, and the existing code will notify the old recipients as well.
[12:50] <deryck> right
[12:50] <deryck> we will have to deal with this notification overhead sooner rather than later, though.
[12:50] <deryck> So someone from the bugs team will look at this in the short term.  if you don't beat us to it, wgrant. ;)
[12:51] <wgrant> It makes kernel bugs just about impossible to file.
[12:53]  * gmb lunches
[13:38] <leonardr> sinzui, when you come in, i'm getting an incomprehensible error message when i ec2 my branch, but not when i run the test locally:
[13:38] <leonardr> http://pastebin.ubuntu.com/497660/
[13:38] <wgrant> Uhoh.
[13:38] <wgrant> Not this again :(
[13:38] <mars> wgrant, ?
[13:39] <wgrant> It's the off-by-one OOPS ID thing.
[13:39] <mars> is there a bug for it?
[13:39] <wgrant> I forget.
[13:42] <lifeless> try it with https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994
[13:42] <lifeless> gnight
[13:42] <wgrant> Night lifeless.
[13:44] <mars> I can't find a bug for it
[13:54] <bigjools-afk> mmmm
[13:55] <bigjools> jml just munched on two faggots for the first time and loved it
[14:09] <StevenK> mars: Hey, did you get my e-mail?
[14:15] <gmb> Ursinha, ping
[14:16] <Ursinha> gmb, hi
[14:16] <gmb> Ursinha, Howdy. So, I keep getting the "Please try again" page when I try to delete this bugwatch: https://bugs.edge.launchpad.net/bugs/642418/+watch/81562/+edit
[14:16] <_mup_> Bug #642418: Detect when remote Bugzilla bugs are duplicates and link to the duped-to bug instead <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/642418>
[14:16] <Ursinha> what my script did wrong
[14:16] <Ursinha> :)
[14:16] <Ursinha> ah
[14:16] <gmb> Ursinha, I don't know why it's not getting an OOPS raised, but do you know where I might be able to look to see if one's been raised but isn't showing up in the UI?
[14:17] <gmb> I'm kinda clutching at straws here, by the way :)
[14:17] <Ursinha> gmb, all oopses are on devpad, let me take a look
[14:17] <gmb> Ursinha, Thanks.
[14:17] <gmb> R%^&QG£YUEHIUDJHIUFHIWUE!!!!!
[14:18] <gmb> You have *got* to be kidding me.
[14:18] <gmb> We add the "bug watch foo has been deleted" notification before we delete the bugwatch.
[14:19] <wgrant> What gets really amusing is when transaction retries come into play.
[14:19] <wgrant> So you end up with lots and lots of notifications.
[14:21] <gmb> wgrant, Indeed. As I just discovered.
[14:21]  * gmb branches and fixes. That one's not hanging around.
[14:24] <Ursinha> gmb, I can't find oopses on devpad
[14:24] <Ursinha> they're synced every 10 minutes, so I guess should be there already
[14:24] <Ursinha> but I can't find anything grepping them
[14:25] <gmb> Ursinha, Thanks. I've found (possibly) a separate problem (see my rant above).
[14:26] <Ursinha> hehe, np
[14:26] <gmb> Ursinha, I'll grep later.
[15:11] <rockstar> gmb, I need to reboot, but then I'd like to chat about the wizard widget.
[15:18] <gmb> rockstar, Sure. thing.
[15:18] <gmb> Er. Sure thing.
[15:27] <gmb> rockstar, I'm ready whenever you are.
[16:22] <nigelb> lifeless: I like the stump speech ;)
[16:34] <mars> leonardr, you missed this fix for your EC2 issue: https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994
[16:35] <mars> StevenK, yes, I got it.  Have been working on other things, will get back to mainline build engineer work this week.
[16:36] <leonardr> mars: is it landed?
[16:37] <mars> leonardr, I don't think so.  Robert said to merge it into yours and then try again.
[16:37] <leonardr> mars: i see
[16:46] <bac> has anyone seen basic auth challenges popping up when running windmill, e.g. http://people.canonical.com/~bac/Screenshot-Authentication%20Required.png
[16:47] <bac> they don't seem to interfere with the tests but are annoying
[16:47] <mars> bac, yes, a known problem since the summer.  Did this just start now?
[16:47] <bac> mars: yeah
[16:48] <bac> mars: just ignore it?
[16:48] <mars> bac, did you just upgrade to Maverick?
[16:48] <bac> mars: last week, yes
[16:50] <mars> bac, so it could be a problem with the test harness under Maverick, or it could be bug 609190
[16:50] <_mup_> Bug #609190: Login problem in windmill test <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/609190>
[16:51] <bac> mars: thanks
[16:51] <mars> bac, try '$ bin/test lp.translations.windmill.tests.test_import_queue', see if that fails
[16:51] <mars> if so, then it is systemic
[16:52] <mars> if not, then it is an issue introduced by new code
[16:58] <henninge> Which style is the right style for headings in doctest? I for get ..
[16:59] <bac> mars the translations test did throw up a bunch of those auth windows but proceeded without error
[16:59] <henninge> == Heading ==
[16:59] <henninge> or
[16:59] <henninge> Heading
[16:59] <henninge> [16:59] <bac> henninge: latter
[16:59] <henninge> cheers bac ;)
[16:59] <bac> henninge: some do
[16:59] <bac> [16:59] <bac> Heading
[16:59] <bac> [16:59] <bac> which seems to be ok unless gmb is your reviewer.  :)
[16:59] <henninge> :)
[17:00] <bac> (but only for the first)
[17:00] <henninge> I was about to ask that ...
[17:02] <mars> bac, ok, noted.  I can check after I do the Maverick upgrade myself.  Was this a fresh system install?
[17:02] <gmb> Oi!
[17:02] <bac> mars: yes
[17:06] <danilos> bigjools, hi, if I was to take on bug 644464, what would be the best approach?
[17:06] <_mup_> Bug #644464: Template generation jobs are not aggregated <Launchpad Translations:Triaged> <https://launchpad.net/bugs/644464>
[17:07] <mars> henninge, danilos, any idea what is up with the latest buildbot failure?  It died in  canonical.buildd.tests.test_translationtemplatesbuildmanager.TestTranslationTemplatesBuildManagerIteration.test_iterate_fail_GENERATE
[17:07] <mars> henninge, danilos, https://lpbuildbot.canonical.com/builders/lucid_lp/builds/171/steps/shell_7/logs/summary
[17:07] <danilos> mars, hum, no, let me take a look
[17:07] <bigjools> danilos: you need to see if a job already exists for the same context; I don't know the best way of doing that for TTBJs
[17:08] <mars> henninge, danilos, nevermind, misread.  It failed in "Error in test lp.buildmaster.tests.test_builder.TestSlave.test_clean", not the translations stuff.
[17:08] <danilos> bigjools, well, I know that much :), I was asking more along the lines of where do you do that for other jobs in soyuz, and if it would be a good thing to do it at the same time?
[17:08] <bigjools> danilos: for soyuz, we allow it, but we detect a more recent version and supersede the old build request instead of dispatching it
[17:09] <bigjools> danilos: but I am worried that you had *so many* requests all queued up
[17:09] <danilos> bigjools, well, we don't have a limit per project yet, but we probably could add that too
[17:10] <bigjools> I think it's a good idea
[17:10] <mars> bigjools, when you are finished talking to Danilo, buildbot died with 'Error in test lp.buildmaster.tests.test_builder.TestSlave.test_clean' - are you the right person to handle that?
[17:10] <danilos> bigjools, anyway, dispatch time is probably the best time if we want to aim for minimum amount of repeated work
[17:10] <bigjools> mars: jml is working on it right now
[17:10] <bigjools> it's a test we added recently and then promptly broke
[17:10] <mars> bigjools, thanks.  jml, could you please send a message to the list about it?
[17:11] <jml> what.
[17:11] <jml> mars, yes, of course
[17:11] <mars> thank you
[17:11] <bigjools> danilos: I would address it on both fronts
[17:12] <danilos> bigjools, well, if I address it on one (considering we are always getting tip of the branch, I can put that limit at 2 which would avoid all the concurrency issues)
[17:12] <danilos> bigjools, I don't see much need for addressing on the other... and vice versa
[17:13] <danilos> bigjools, btw, what was the number of builds that we had scheduled?
[17:13] <bigjools> danilos: ok, I'm no so familar with the dynamics of how and when you generate the jobs so I trust whatever you say
[17:13] <danilos> bigjools, good :)
[17:13] <danilos> bigjools, or not so good, but anyway :)
[17:13] <bigjools> :)
[17:13] <bigjools> danilos: I don't know how many were scheduled
[17:13] <bigjools> but, one sec
[17:15] <danilos> bigjools, I see we did at least 360 for software-center
[17:15] <bigjools> !
[17:15] <danilos> bigjools, in one day :(
[17:15] <bigjools> https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20100921/20100923/
[17:15] <bigjools> ummm
[17:16] <danilos> bigjools, it definitely sounds as if something was wrong elsewhere as well
[17:17] <bigjools> I expect someone uploaded a bunch of stuff, somewhere
[17:17] <danilos> bigjools, because that particular branch only had 9 commits on 21st (when it did 360 template build jobs)
[17:18] <bigjools> danilos: that's.... special
[17:18] <danilos> bigjools, yeah, so somewhere on the code side we generated a bunch of duplicated jobs needlessly
[17:19] <danilos> bigjools, so, I'd like to investigate this a bit, and will end up limiting the number of entries in the table per project to 2 anyway, but would like to check out why is this happening in the first place
[17:20] <danilos> bigjools, or perhaps we are retrying them for some reason? under what conditions does build-manager retry a build (just so I can check we are not causing it to do that)?
[17:21] <bigjools> danilos: that's down to the behaviour class for templates
[17:21] <bigjools> the b-m just picks the next item from the queue and dispatches it
[17:21] <danilos> bigjools, ok, since we haven't implemented that, we should not worry about it
[17:22] <danilos> bigjools, thanks, useful input, I'll go dive into code a bit
[17:23] <bigjools> danilos: np
[17:25] <bigjools> danilos: can you kill off all the unnecesary duplicated TTBJs in production?
[17:25] <bigjools> and unnecessary, even
[17:25] <danilos> abentley, btw, do you know of any way to check if branch-scanner has recently been detecting a single change more than once (I am looking at logs but I can't find current branch-scanner logs on devpad)
[17:25] <danilos> abentley, never mind, it's scan-branches.log
[17:27] <danilos> bigjools, sure, though it will take me a bit to rediscover all the tables that I need to purge from
[17:29] <bigjools> danilos: see mawson:~/handy_sql/kill_a_build.sql for inspiration
[17:29] <danilos> bigjools, thanks
[17:46] <abentley> jtv, around?
[17:51] <danilos> abentley, he should be long gone
[17:52] <abentley> danilos, mostly, but I have seen him around in the past.  I'm having problems with the FakeLibrarian.
[17:52] <bigjools> danilos: hi
[17:52] <danilos> bigjools, hi :)
[17:53] <danilos> abentley, yeah, he does sometimes stick for much, much longer, but we are also trying to get that habit out of him :)
[17:53] <bigjools> there's a rather large problem with builder histories being absent since about 6 hours ago, did you guys  change anything for your history?
[17:53] <danilos> bigjools, those changes only landed on devel a few days ago, are you talking about production?
[17:53] <bigjools> yes
[17:54] <danilos> bigjools, unless this was CPed in line with lifeless' new approach to rolling out stuff, then we haven't changed anything recently
[17:54] <bigjools> danilos: that's what I am wondering
[17:55] <bigjools> it seems remarkably coinciding
[17:55] <bigjools> what time did it get rolled out
[17:55] <bigjools> today
[17:55] <danilos> bigjools, did it get rolled out?
[17:56] <bigjools> I;'ve no idea, I only just started looking at this
[17:59] <danilos> bigjools, this is the last one: https://code.edge.launchpad.net/~lifeless/launchpad/cp/+merge/35965
[18:00] <bigjools> danilos: what revno did the ttbj history land in?
[18:00] <bigjools> and was it on db-devel or devel?
[18:00] <danilos> bigjools, I am looking that up now
[18:01] <danilos> bigjools, fwiw, it's still marked as qa-needstesting for us, so I doubt it was CPed
[18:01] <danilos> bigjools, it's db-stable r9793
[18:02] <danilos> bigjools, so, my guess is that it ain't that
[18:02] <danilos> bigjools, it's neither listed as part of any of the CPs
[18:03]  * bigjools scratches head
[18:12] <danilos> bigjools, fwiw, I am struggling very much coming up with appropriate queries for the DB (I started using the new table jtv added and the query failed on production)
[18:12] <danilos> bigjools, that, at least, confirms that the code was not rolled out, but also makes my head hurt
[18:12] <bigjools> the new model is a total headache :/
[18:13] <danilos> bigjools, two models are a bigger one when you rarely use either :)
[18:14] <bigjools> aye
[18:35] <mtaylor> spiv: you awake yet?
[18:36] <mtaylor> or really any losa - there is a chance that there may be a memory issue on maverick ppa builders ... we're seeing a drizzle test failure there that we're not seeing on our builders, and looking at the output it looks very similar to a weird failure we had on a machine a month ago that was also due to bad memory
[18:37] <mtaylor> I mean, it could also be a bug in our code - but I thought it might be worth someone looking at
[18:40] <mtaylor> http://launchpadlibrarian.net/52012953/buildlog_ubuntu-maverick-i386.drizzle_2010.03.1347-1_FAILEDTOBUILD.txt.gz
[18:42] <mtaylor> hrm - perhaps nevermind ... similar but different is occuring in multiple places ...
[18:59]  * rockstar lunches
[19:00] <mtaylor> quick followup - it is our bug, but for some reason it's only showing up on the launchpad ppa 32 builders and not our 32 build machines ... are you guys doing anything weird on your 32bit builders which would cause them to deal with memory differently? (asking to see if I can set up something similar to try to more easily reproduce)
[19:01] <jml> mtaylor, there's an issue that we are investigating right now
[19:02] <jml> mtaylor, but apparently that's a different problem
[19:02] <mtaylor> cool
[19:05] <bryceh> deryck[lunch], on 642418 is it LP or the bugzilla lp plugin that sets the See Also link?
[19:05] <bigjools> mtaylor: the PPA builders are virtual, which might be something, I dunno
[19:05] <bigjools> mtaylor: but it's best to check with lamont
[19:34] <bryceh> deryck[lunch], lp:~bryceharrington/bugzilla-launchpad/no-dupe-link-update
[19:37]  * lifeless stretches
[19:40] <lifeless> nigelb: ?
[19:40] <deryck> bryceh, not sure if it's the plugin or lp.  If it's the plugin, it may not be worth worrying too much about, since people will need to install new, and newer bugzillas won't be affected.
[19:41] <bryceh> deryck, since it sounds like it's a bugzilla policy whether to update links on dupe bugs, the plugin seems like the "right" place to fix it
[19:42] <bryceh> deryck, as that'd prevent the incorrect behavior regardless of who was using the api
[19:42] <bryceh> deryck, but for our case at least, i think we can conditionalize calling the set_link() api on it being a dupe... I'm checking
[19:43] <bryceh> (and it still leaves the more general issue of making us point to the proper bug, but I *think* that may be a more involved issue)
[19:43]  * deryck is thinking....
[19:44] <deryck> bryceh, so the plugin is already configurable about whether or not to update links on dupe bugs?
[19:45] <bryceh> deryck, no
[19:45] <bryceh> heh that would make it especially easy
[19:45] <bigjools> lifeless!  I'm surprised you don't have some way of accessing IRC when you're sleeping
[19:46] <bryceh> bigjools, isn't that called a telephone?
[19:46] <bigjools> or is this your morning clone I am speaking to
[19:46] <lifeless> bigjools: I plug an ethernet cable into my ear.
[19:46] <jml> wifi drains too much power in sleep mode
[19:47] <deryck> bryceh, ok, so I think we should do the right think on our end.
[19:47] <deryck> bryceh, if it's just a simple conditional to be quiet on upstream closed bugs, that's enough.
[19:48] <bryceh> deryck, yes, it looks like I can slot in a check in linkLaunchpadBug()
[19:48] <deryck> bryceh, ok, excellent.
[19:49] <jml> hello everyone
[19:49] <bryceh> deryck, this will only prevent it from setting the bug link on the upstream bug though... are there other updates we want to prevent done to upstream dupes?
[19:49] <jml> bigjools & I just finished busting up a bunch of doctests
[19:49] <jml> but we need to land the change, and I think someone ought to give it a cursory review first
[19:49] <nigelb> lifeless: I just said your stump speech http://bit.ly/9mTfdf looks awesome :)
[19:49] <bigjools> it's death to .txt
[19:49] <jml> who would like to review https://code.edge.launchpad.net/~jml/launchpad/buildd-slavescanner-bustage/+merge/36187, which is 1k+ lines of doctest-removing fun?
[19:50] <lifeless> nigelb: ah right, I had no idea what you were referring to by 'stump speech'
[19:50] <deryck> bryceh, perhaps you and gmb should do a pre-imp on this tomorrow before he EODs.  I'm not sure about other updates honestly.
[19:50] <lifeless> nigelb: I'm glad you like it.
[19:50] <nigelb> lifeless: the bzr team called it that
[19:51] <jml> anyway, I'm off to the pub
[19:51] <lifeless> nigelb: its ok, I was just confused ;)
[19:51] <jml> whoever reviews that branch gets a complimentary compliment at the next Epic
[19:51] <jml> maybe a beer too
[19:51] <nigelb> lifeless: considering that it must be something like 5 for you, totally understandable
[19:52] <lifeless> nigelb: 7 :P
[19:52] <nigelb> lifeless: still way to early ;)
[19:52] <deryck> bryceh, the only other updates we would do would be comments, if supported, right?
[19:52] <bryceh> deryck, dunno
[19:53] <bryceh> deryck, yes
[19:53] <deryck> bryceh, I think so, but not 100% sure.  I can argue boths pros and cons here, so let's allow gmb the final say.
[19:53] <bryceh>            # Only sync comments and backlink if the local bug isn't a
[19:53] <bryceh>             # duplicate and the bug watch is associated with a bug task.
[19:53] <bryceh>             # This helps us to avoid spamming both upstream and
[19:53] <bryceh> 	    # ourselves.
[19:53] <lifeless> ok, lets see how bad this bugtask index test breakage is
[19:54] <bryceh> haha, we avoid updating if the bug is a dupe on *our* end, but not *their* end :-P
[19:54] <deryck> heh
[19:54] <deryck> right, so there's your answer.
[19:54] <deryck> bryceh, if there's is a dupe, do nothing.
[19:55] <bryceh> deryck, ok, so don't bother with fixing the plugin, just fix locally?
[19:55] <deryck> bryceh, yes
[19:55] <bryceh> ok easy enough
[20:02] <lifeless> sigh, bug.getBugTask makes me sad.
[20:03] <jam> lifeless: I seem to be getting spurious failures when asking people to ec2land branches for me. I'm not really sure who to ask for help
[20:03] <jam> but I see you online :)
[20:04] <lifeless> jam: hi, what sort of failures?
[20:05] <jam> lifeless: I can send you the email if that would be easier
[20:05] <jam> but 2 in soyuz
[20:05] <lifeless> sure
[20:05] <jam> one in buildmaster
[20:07] <bigjools> good night all
[20:07] <jam> lifeless: my change just updates the default location of 'codebrowse's config files after a clean 'make'
[20:12] <jam> lifeless: to elaborate, when starting with a clean machine, the build instructions didn't create the 'codebrowse.launchpad.dev' directory but they *do* create a 'bazaar.launchpad.dev' directory, which is also what is configured elsewhere in the code. I honestly wouldn't expect any tests to fail from this, as it is a setup thing.
[20:12] <jam> certainly it doesn't touch soyuz code
[20:13] <lifeless> jam: do those tests pass locally ?
[20:13] <lifeless> jam: note that ec2 doesn't do a full setup, it starts partially setup AIUI
[20:13] <lifeless> jam: perhaps talk with mars
[20:14] <jam> lifeless: well, the last code I submitted was a comment-only change, and it still failed the ec2land test suite (for one person, for the other person it passed)
[20:14] <jam> as such, I don't have huge faith in ec2land...
[20:14] <jam> though that time was a different test that failed
[20:21] <lifeless> jam: will be a minute
[20:47] <cr3> gary_poster: got a minute for a question about z3c.recipe.scripts? having problems importing lazr.restfulclient in /usr/lib/pymodules after importing the generated site.py file
[20:51] <jam> bac: ^^
[20:51] <bac> oh, great
[20:51] <jam> so if the tests are already failing, it may be a particular version of devel that I merged, etc
[20:51] <jam> I suppose I should have merged something 'stable' ?
[20:51] <bac> jam: did you not start with the latest devel?
[20:52] <bac> i mean the latest rev of devel
[20:52] <jam> bac: I started the branch a while back, you asked me to update against devel so I did
[20:53] <bac> jam: right.
[20:53] <jam> I also may have started it as a db-devel branch, etc
[20:53] <jam> I would have thought by now the two would have converged, though, and the diff was the tiny one I expected
[20:54] <bac> jam: i started with a clean version of the latest devel and merged in your two-line change
[20:54] <jam> and you still got the failure?
[20:54] <bac> jam: and that is what i'm testing locally
[20:55] <bac> jam your branch on LP is what ec2 tested
[20:55] <jam> (missing shows that I am without about 48 devel patches)
[20:59] <jam> bac: are you running the full suite? Or just the tests that failed?
[20:59] <bac> jam: just the failed
[20:59] <jam> good to know they fail in isolation :)
[21:02] <jam> (I'm still trying to just get the test suite to run again, after updating to the latest lp/devel)
[21:02] <bac> jam: ec2 had 4 failures.  devel locally has 1.
[21:02] <bac> jam: will re-run your branch again and see what fails
[21:03] <jam> bac: well one of the failures definitely looked to be an isolation issue, since it was checking for OOPS...6 and found OOPS...7
[21:03] <bac> ok
[21:03] <lifeless> ok
[21:03] <lifeless> so this is the same uniquefileallocator thing
[21:04] <lifeless> try with my branch?
[21:04] <lifeless> I'm waiting for *anyone* to tell me it works/doesn't work
[21:04] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/lessGetLastOops/+merge/35994
[21:05] <jam> lifeless: what is the right way to update your branch? I tried "utilities/update-sourcecode" and now zc.buildout is failing at 'make' time
[21:05] <bac> jam:  your branch has 1 failure locally, not the OOPS one
[21:05] <gary_poster> cr3: do you have include-site-packages = true in your .cfg file?  That will be the default in 1.5.2 but false is default before then
[21:05] <jam> bac: is it the same one that 'devel locally' has ?
[21:05] <bac> lp.soyuz.tests.test_buildpackagejob.TestBuildPackageJobScore.test_score_unusual_component
[21:06] <bac> jam:no.  devel has the OOPS failure.  your branch has ^^
[21:06] <cr3> gary_poster: yes
[21:06] <jam> bac: well having it fail 3-different ways doesn't make me very trusting
[21:06] <bac> nope
[21:07] <cr3> gary_poster: I'm kinda confused why import can't find restfulclient under /usr/lib/pymodules/python2.6 when that path is actually in sys.path
[21:07] <lifeless> jam: you may need an apt-get update && apt-get upgrade in there
[21:08] <gary_poster> cr3: can you give me instructions to dupe maybe?  want to help, but also have some other people to support right now
[21:08] <cr3> gary_poster: it seems that if I introduce /usr/lib/pymodules/python2.6 in the buildout_paths, in site.py, before the zope.exceptions egg path, then I can import lazr.restfulclient
[21:08] <jam> lifeless: did that, now I'm trying an update of the "download-cache" directory
[21:08] <jam> (bzr update)
[21:09] <gary_poster> not a good long-term solution cr3: setuptools won't work the right way like that
[21:09] <jam> which did pull in a bunch of stuff
[21:09] <cr3> gary_poster: I'll try to figure a way to easily dupe and get back to you
[21:09] <gary_poster> thanks cr3
[21:09] <cr3> gary_poster: zc.recipe.egg seems to order paths correctly though
[21:09] <jam> I don't know why it didn't update with everything else...
[21:09] <jam> at this point, I'm ready to turn to a voodoo doll
[21:09] <gary_poster> cr3 what definition of correc?
[21:09] <cr3> gary_poster: works :)
[21:10] <gary_poster> fair enough, cr3.  does not work in other circumstances though.
[21:10] <jam> lifeless: updating download-cache was enough to get 'make' to run
[21:11] <cr3> gary_poster: ugh, so if I use both zc.recipe.egg and z3c.recipe.scripts, I don't work in all circumstances :)
[21:11] <gary_poster> cr3: correct.  z3c.recipe.scripts is supposed to be your one-stop-shop.
[21:11] <gary_poster> (the fact that it is not is a bug, obviously)
[21:12] <gary_poster> zc.recipe.egg will not change
[21:12] <cr3> gary_poster: I'll concentrate on porting my existing zc.recipe.egg stuff to z3c then
[21:12] <gary_poster> cool, cr3.
[21:13] <lifeless> don't you hate it when adding an assert makes things work ...
[21:20] <mars> leonardr, still around?  Did you get a chance to try lifeless's OOPS patch?
[21:20] <leonardr> mars: well, it's in ec2. i didn't get the problem locally
[21:20] <lifeless> Ursinha: could we have a 'latest' or 'current' symlink for the oops report html file ?
[21:21] <Ursinha> lifeless, it's always the deployment-stable one
[21:21] <lifeless> different hting
[21:21] <lifeless> like https://devpad.canonical.com/~lpqateam/oops-summaries/lpnet-oops-last-hour.txt
[21:21] <lifeless> but for the day
[21:21] <mars> jam, any luck?  Normally to update LP you can run 'rocketfuel-get; cd mybranch; bzr merge ../devel'
[21:22] <lifeless> I thought there was one, but I can only find things for specific dates, not one I can put in by bookmarks.
[21:22] <mars> leonardr, the branch with the patch is in EC2?  Or just the plain old branch?
[21:23] <leonardr> the branch with the patch is in ec2
[21:23] <mars> lifeless, ^
[21:23] <jam> mars: well, things almost seem to work, but I still am trying to determine how to run a subset of the test suite based on failures from ec2
[21:23] <jam> at least the test runner starts up and runs some tests and exits appropriately
[21:23] <lifeless> leonardr: cool, thanks
[21:24] <lifeless> jam: testr load < subunit-stream; testr run --failing
[21:24] <mars> jam, ok, in the branch: testr init; (save log.gz from ec2 to disk); zcat foo.log.gz | testr load; testr failing
[21:25] <Ursinha> ah
[21:25] <bac> jam, lifeless: the failure i'm seeing is real and is going to put us in testfix mode very soon now.  https://lpbuildbot.canonical.com/builders/lucid_lp/builds/172/steps/shell_7/logs/stdio
[21:25] <bac> search for test_score_unusual_component
[21:25] <mars> \o/
[21:25] <Ursinha> lifeless, I see what you want
[21:26] <lifeless> Ursinha: for that one html would be nice :)
[21:26] <lifeless> Ursinha: just needs to be a symlink to 2010-09-21.html, etc etc
[21:26] <Ursinha> lifeless, I got it
[21:26] <jam> bac: so ec2land doesn't pre-merge the target branch and run the tests on the result?
[21:26] <lifeless> bac: was that landed without ec2land? do we know?
[21:26] <bac> jam: yes it does
[21:26] <mars> jam, ec2 land branches devel, then merges your branch, then runs the tests
[21:27] <bac> lifeless: we have no way of knowing
[21:27] <jam> ah, I was hoping so
[21:27] <lifeless> jml: yo
[21:27] <bac> since it is soyuz i'd say not
[21:27] <bac> i should rephrase
[21:27] <lifeless> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/172/ is about to die and you're in the blame list. Should we rollback your commits ?
[21:27] <bac> bigjools does his testing locally.
[21:28] <bac> lifeless: who was that directed to?
[21:28] <lifeless> jml:
[21:28] <mars> jam, it was written by bzr folk - pre-merge is not natural, but all of you have learned to The Right Way To Do It
[21:28] <lifeless> mars: pre-merge?
[21:29] <mars> lifeless, is that not what jam just called it?  "so ec2land doesn't pre-merge the target branch and run the tests on the result?"
[21:29] <bac> lifeless: yes, it is certainly jml's r11586
[21:29] <lifeless> mars: 'EPARSE' on your last
[21:29] <lifeless> bac: land a backout of it
[21:29] <lifeless> bac: if you would
[21:29] <lifeless> and 11588 I guess, I'm assuming that that was an attempt to fix it that didn't
[21:30] <bac> lifeless: so how would i do that?
[21:30] <mars> bac, please use "ec2 land --rollback 11586", or 'bzr lp-land --rollback 11586'
[21:31] <mars> bac, that way the QA flags will be correct
[21:31] <bac> mars: you rock!
[21:31] <lifeless> bac: bzr lp-land --rollback 11586
[21:31] <lifeless> bac: bzr lp-land --rollback 11588
[21:31] <lifeless> and then it should go its merry way
[21:31] <lifeless> actually
[21:31] <lifeless> mars: is that only commit message glue, or does it do the roll back merge too ?
[21:32] <mars> bac, by the way, you have to acutally run 'bzr merge 11586..11585'
[21:32] <lifeless> so, the full story then:
[21:32] <lifeless> bzr branch devel testfix
[21:32] <lifeless> in testfix
[21:32] <mars> (this is all in the not-yet-seen-but-does-exist user guide)
[21:32] <lifeless> bzr merge . -r 11586..11585
[21:32] <lifeless> bzr merge . -r 11588..11587 --force
[21:33] <lifeless> bzr commit -m "Rollback 11586 and 11588"
[21:33] <lifeless> bzr lp-land --rollback 11586 --rollback 11588
[21:33] <lifeless> mars: ^ sane?
[21:33] <mars> lifeless, I hope so.  I don't know if the tagger or lp-land can take multiple --rollbacks
[21:33] <bac> seems right to me, though i would've forgotten the .
[21:33] <lifeless> mars: if it doesn't, it will need to ;)
[21:34] <mars> if it doesn't, we can roll each back on it's own maybe?
[21:34] <mars> bac, try it
[21:34] <mars> test flight!
[21:34] <bac> mars: trying
[21:34] <bac> still generating me some wadl
[21:34]  * mars hope's bac's branch doesn't end up in a smouldering crater
[21:35] <mars> I can watch the tagger logs
[21:36] <mars> ah, maybe not.  There is a 4? hour lead time on landings
[21:36] <mars> puts is around 8:30 or 9pm here
[21:36] <bac> mars: what plugin provides lp-land?  mine doesn't have --rollback
[21:37] <mars> bac, bzr-pqm
[21:37] <bac> mars: i need to install from lp:pqm?
[21:37] <mars> bac, sorry, 'pqm' is the plugin, bzr-pqm is the ubuntu package
[21:37] <bac> mars: is there a ppa?
[21:37] <mars> bac, yes, it is in the LP ppa - what version do you have?
[21:38] <mars> apt-cache policy bzr-pqm
[21:38] <bac> ii  bzr-pqm                 1.4.0~bzr69-1           bzr plugin to submit an email to a Patch Queue Manager
[21:38] <mars> out of date
[21:38] <mars> 1.4.0~bzr73-0ubuntu1-launchpad1~lucid1
[21:38] <mars> why, it needs a maverick build?
[21:38] <bac> not.  on.  lucid.
[21:38] <bac> no one should be on lucid
[21:39] <bac> we all have to jump the broom together
[21:39] <bac> or something like that
[21:39] <bac> i think i confused roots with thelma and louise
[21:40] <bac> mars would you mind trying the rollback since i'm crippled?
[21:40] <mars> ok, having no series on the PPA page package list is a little annoying
[21:40] <bac> jam, please ping me tomorrow and i'll try again
[21:40] <mars> wasn't there supposed to be JavaScript on this page?
[21:41] <mars> bac, ok, what is the branch, just devel?
[21:41] <bac> mars: yes, devel.
[21:41] <mars> bac, here is your problem: https://edge.launchpad.net/~launchpad/+archive/ppa?field.series_filter=maverick
[21:41] <bac> trying to undo changes 1 and 3 from https://lpbuildbot.canonical.com/builders/lucid_lp/builds/172/
[21:42] <mars> compare to: https://edge.launchpad.net/~launchpad/+archive/ppa?field.series_filter=lucid
[21:42] <bac> yes, many fewer
[21:42] <mars> some are legitimate, like python-debian
[21:42] <mars> others are oversights
[21:42] <mars> adding that to my TODO list
[21:43] <mars> bac, running it now
[21:44] <bac> is celso really still uploading PPAs for us?
[21:44] <bac> re: geoip on maverick
[21:48] <jam> bac: I'll say hi tomorrow, thanks for working with me on this
[21:48] <bac> jam: sorry we had so much fail for what should've been easy
[21:50] <jam> lifeless: so how in the 'testr' stuff do you run just the failing tests?
[21:50] <jam> testr run looks like it runs everything
[21:50] <lifeless> testr run --failing
[21:51] <jam> ah, testr run --failing
[21:52] <mars> bac, waiting for the MP to show up, I'll need you or lifeless to approve it to appease lp-land
[21:52] <bac> mars: rs=me
[21:52] <lifeless> rs=theworld
[21:52] <bac> mars: oh, right, on the MP
[21:53] <rockstar> Wow, Chromium consistently crashes X for me now.
[21:53] <mars> rockstar, eeew
[21:54] <rockstar> mars, what's worse is that it seems to happen whenever I'm REALLY focused on what I'm doing.
[21:54] <mars> X crashes are not fun.  I've had my share of those.
[21:54] <mars> yeah
[21:54] <mars> at least an application freeze is humane.  An X crash is just brutal.
[21:55] <jml> lifeless, hello. what's up?
[21:55] <jam> lifeless: trying to run "testr run --failing" gives me: http://paste.ubuntu.com/497981
[21:55] <jam> which seems like a test system infrastructure issue
[21:56] <mars> bac, https://code.edge.launchpad.net/~mars/launchpad/rollback-11586-and-11588/+merge/36212
[21:57] <wallyworld___> morning
[21:57] <jml> jam, yeah. I've been meaning to chase down that bug.
[21:57] <lifeless> jml: bb found a flaw in your branch
[21:57] <lifeless> jml: we're backing it out
[21:57] <jml> lifeless, :(
[21:57] <jml> lifeless, can't I just fix it instead?
[21:58] <jam> jml: well, it *does* take 4 hours to land the reversal
[21:58] <lifeless> jml: it looks like you've tried once already; its an unknown amount of time before we find all the issues and we don't want to be in testfix for that long.
[21:58] <jml> lifeless, wrong.
[21:58] <mars> ok, trying lp-land
[21:58] <jml> lifeless, different problem.
[21:58] <mars> ...
[21:58] <lifeless> mars: hang a sec
[21:58] <mars> (nice timing)
[21:58] <lifeless> jml: please expand;
[21:59] <jml> lifeless, the first test fix was for a different failing test with a completely different problem: not having a clean() method on build
[21:59] <lifeless> jml: [separately, meta] are you landing these things via ec2 land ?
[21:59] <jml> lifeless, the failure you see now is due to a different problem due to a change to the API of a factory method
[21:59] <jml> lifeless, no, I'm not.
[21:59] <lifeless> jml: please do.
[21:59] <jml> lifeless, I normally do.
[21:59] <lifeless> jml: well, please do what you normally do.
[21:59] <jml> lifeless, ok.
[22:00] <lifeless> jml: not doing it has spent about 1/2 an hour of engineer time
[22:00] <mars> x3
[22:00] <lifeless> jml: how confident are you that there are no other issues behind this one
[22:00] <bac> mars:done
[22:00] <jml> lifeless, sure. I know how tedious it is to fix other people's broken builds.
[22:01] <jml> lifeless, quite confident.
[22:01] <lifeless> ok, I'm happy with 'fix it' - but if we head back into testfix from another issue in the same patch in 4 more hours, I'll roll it back and let you debug tomorrow, ok?
[22:01] <jml> lifeless, +1
[22:02] <mars> lifeless, jml, so if need be, we roll back both with https://code.edge.launchpad.net/~mars/launchpad/rollback-11586-and-11588/+merge/36212 ?
[22:02] <mars> lifeless, or will you prepare a new patch?
[22:02] <jml> mars, I'd rather you rollback only 11588
[22:02] <lifeless> jml: landing without ec2 land is ok from time to time - you know me and pragmatism; I guess I'm saying that the work you're doing is stuff I wouldn't have attempted to land without full tests :)
[22:02] <lifeless> mars: I'll leverage that one, if needed
[22:02] <mars> lifeless, ok, I'll leave it to you and jml then
[22:03] <lifeless> mars: thanks
[22:03] <lifeless> mars: can you confirm that when bb *starts* a build pqm opens again ?
[22:03] <bac> yeah, thanks mars
[22:03] <bac> lifeless: that is true
[22:03] <jml> lifeless, as I said, normally, I wouldn't either.
[22:04] <mars> bac, the 'pqm opens again' is true?
[22:04] <mars> I don't actually know
[22:04] <bac> when bb starts on at [testfix] it optimistically takes us out of testfix mode
[22:05] <lifeless> bac: thats a different question
[22:05] <lifeless> bac: what I asked is 'starts a build' - thats 'receives a testfix commit'
[22:05] <lifeless> bac: many testfixes are spurious
[22:06] <jml> lifeless, waiting eight hours before I can meaningfully integrate is particularly trying at a sprint. :\
[22:06] <lifeless> yeah
[22:06] <bac> lifeless: what do you mean many testfixes are spurious?
[22:07] <lifeless> bac: I mean our test suite is as flaky as 'Flake(tm)' chocolate
[22:07] <bac> lifeless: i assumed you meant pqm was closed due to testfix mode
[22:07] <lifeless> yes, thats what I mean
[22:07] <bac> then bb won't start again until it receives a testfix, right?
[22:07] <lifeless> a non trivial amount of the time just running the test suite again will work.
[22:07] <lifeless> bac: no, you can press 'force build'
[22:08] <mars> but that does not open PQM again
[22:08] <bac> lifeless: so you are asking if forcing a build while in testfix mode opens pqm.  that i do not know
[22:08] <lifeless> mars: it doesn't? Ok, can we make it do so?
[22:09] <mars> lifeless, no idea.  That means the poller bit would have to know the difference between a forced build and a testfix build.  Would take some work.
[22:09] <lifeless> mars: why would it need to know the difference?
[22:09] <bac> mars: making it know the difference would argue that it currently would open pqm
[22:10] <mars> yep, you are right.  I was thinking 'if you only want to open PQM when a build is forced, then you need to do some footwork'
[22:10] <jml> lifeless, I object to your statement about our test suite being flaky. The tests themselves very, very rarely fail spuriously.
[22:10] <mars> tunnel vision, not helpful, sorry
[22:11] <lifeless> jml: layers fail to come up; windmill on the lp builder is almost always dying, we have hung librarian processes a lot of the time
[22:12] <jml> lifeless, yes, but the tests themselves...
[22:12] <jml> lifeless, everything else never works, sure.
[22:13] <lifeless> jml: I referenced the 'test suite', which is the whole
[22:13] <mars> lifeless, ?  I haven't seen any of those issues in a while.  Recently it has been the DB connections thing.  and XMLRPC code pulls fail.
[22:13] <jml> :D
[22:13] <lifeless> mars: yesterday.
[22:13] <lifeless> mars: lp build, lp_db, go boom.
[22:13] <lifeless> also
[22:13] <lifeless> this is bad:
[22:13] <cr3> gary_poster: it seems the problem might be related to bug #599332, now I'm getting: Error: Couldn't find a distribution for 'elementtree'. Still working on it...
[22:13] <_mup_> Bug #599332: python-lazr.enum makes python-lazr.restfulclient no longer be visible <lazr.restfulclient (Ubuntu):Fix Released> <https://launchpad.net/bugs/599332>
[22:13] <lifeless> Danger Zone.
[22:13] <lifeless> enter makeBugTask.
[22:13] <lifeless> 233525392 16
[22:13] <lifeless> 233525392 16
[22:13] <lifeless> 233525392 16
[22:13] <lifeless> 234934992 16
[22:14] <lifeless> enter makeBugTask.
[22:14] <lifeless> 233525392 16
[22:14] <lifeless> thats id(bug), bug.id
[22:14] <lifeless> in one call to makeBugTask()
[22:14] <lifeless> notice that we have two objects claiming to be the same bug, live at once.
[22:14] <wallyworld___> thumper: standup?
[22:15] <mars> lifeless, if you are wondering about the hardy builders, we haven't been maintaining them
[22:15] <mars> yes, they blow up, because we aren't fixing the problems
[22:15] <lifeless> mars: which demonstrates my point about flakiness ;)
[22:15] <gary_poster> cr3: :-) I'm sorry.  If you can just give me dupe instructions, I'll swim in themorass for you
[22:15] <lifeless> the lp test environment is not a 'fire and forget' one.
[22:16] <lifeless> its forget, and you're on fire.
[22:16] <gary_poster> cr3: IOW, I advise trying to keep from figuring out what's actually going on--but if you do, that's great
[22:16] <cr3> gary_poster: heh, that's really nice but I'm trying to spare you too much distraction
[22:17] <cr3> gary_poster: in that case, I'll try to push a branch which can reproduce the problem for you. one moment...
[22:18] <gary_poster> cr3: great thanks.  You may have to give me apt package names that you have installed that you suspect are causing the problem.  It may also be lucid or maverick or something, so let me know what that is
[22:18] <jml> one line diff: https://code.edge.launchpad.net/~jml/launchpad/fix-factory-change/+merge/36215
[22:19] <mars> jml, if you are asking 'does this pass our code standards', then yes! r=mars.  If you are asking if you missed anything critical in this patch, well, I have no idea :)
[22:20] <jml> mars, good enough for me.
[22:21] <mars> jml, done
[22:21] <jml> mars, ta.
[22:22] <jml> landing now.
[22:22] <lifeless> I'd really quite like to delete most of our coding standards I think.
[22:22] <lifeless> they seem, the more code I read, to be a poor surrogate for what we say we care about
[22:26] <mars> lifeless, to be honest, I mostly review for readability now - a Smalltalk-influenced ideal I believe we should strive towards
[22:26] <mars> and all-around quality - more robust tests, using the right test type for the purpose and such
[22:28] <lifeless> mars: things like lines ending on 78/79/80, (,) vs (, ), what case to use for function names seem largely content free
[22:28] <mars> oh, and for codebase design improvements - "we have a helper for that", or "this would be great as a new helper"
[22:28] <cr3> gary_poster: email sent
[22:28] <lifeless> mars: thats sensible
[22:29] <mars> lifeless, true, but standards are nice.  When one person codes to C, one to Java, and one to Smalltalk, things look... not as nice as they could be, to the other people
[22:29] <mars> and in Python as a whole, I have seen all three
[22:29] <gary_poster> cr3, ack, investigating
[22:29] <mars> styles, that is
[22:29] <lifeless> mars: if we're going to use a standard, we should use a standard.
[22:29] <lifeless> mars: not make our own
[22:29] <lifeless> mars: because we interoperate with the rest of the python world
[22:30] <lifeless> mars: I would simply say 'be roughly PEP8, make it readable, thanks.'
[22:30] <gary_poster> cr3: maybe I don't have privs to see?
[22:30] <jml> PEP 8 (alternatively, bzrlib's or Google's Python standard)
[22:31] <cr3> gary_poster: maybe I've been working too hard on this and I forgot to push that branch :)
[22:32] <cr3> gary_poster: it's done now, sorry about that
[22:32] <gary_poster> jml, lifeless, mars, changing coding standards in the middle of a codebase, particularly when you are talking about things that affect API, like camelcase versus underlines, doesn't seem like a great idea to me, but...eh, flyby :-) .
[22:32] <jml> gary_poster, yeah, that's the other issue
[22:32] <gary_poster> cr3: got it, thanks :-)
[22:33] <jml> gary_poster, especially now that we've got an external API to preserve
[22:33] <gary_poster> well, we can adjust that
[22:33] <gary_poster> but still
[22:33] <gary_poster> unless we have a magic "change everything at once"
[22:33] <gary_poster> I'm -1
[22:34] <gary_poster> Which is funny in a way
[22:34] <gary_poster> But I need to move on :-)
[22:34] <cr3> jml: I've I'm writing a brand spanking new API, is there anything I should consider from this conversation about coding style?
[22:34] <jml> cr3, no.
[22:34] <gary_poster> PEP 8 :-)
[22:34] <lifeless> cr3: make it tasteful.
[22:34] <lifeless> gary_poster: changing public apis has consequences, yes.
[22:34] <cr3> lifeless: to me, it tastes just the same camelcase vs underlines
[22:34] <cr3> lifeless: ... as long as it's consistent with the context
[22:34] <lifeless> use whitespace then, to add flavour
[22:35]  * cr3 adds salt (random bits) to taste
[22:36] <gary_poster> don't give me that branch, cr3 ;-)
[22:36] <gary_poster> cr3: maybe you haven't checked in things to download-cache?
[22:36] <gary_poster> missing wsgi-interceptm for instance
[22:37] <gary_poster> can work around
[22:38] <jml> anyway, my yak stack is pretty deep with things that actually bug me about LP development. coding standard is well low.
[22:38] <cr3> gary_poster: installed as package, I should add to setup.py
[22:38] <gary_poster> cr3: ok.  got it as egg here
[22:40]  * jml is hanging around until PQM says my branch has landed
[22:40] <cr3> gary_poster: ./bin/test, are you getting the same error as me?
[22:41] <poolie> hello all
[22:41] <gary_poster> cr3, doing it a different way, but I think so :-)
[22:41] <lifeless> poolie: hi
[22:41] <poolie> hi lifeless
[22:41] <lifeless> early for you? Anyhow I could use a hand
[22:41] <lifeless> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/634342
[22:41] <_mup_> Bug #634342: need a features 'scope' for page ids <qa-ok> <Launchpad Foundations:Fix Committed by lifeless> <https://launchpad.net/bugs/634342>
[22:41] <poolie> slightly early
[22:41] <poolie> yes i saw
[22:41] <poolie> i would presume from that output that it is getting the value for memcache in that scope
[22:42] <poolie> unless you defined it at a lower prioirity than the default
[22:42] <poolie> clearly there's room for better docs and tests there
[22:42] <lifeless> there was only one rule defined in the db
[22:42] <cr3> gary_poster: regarding wsgi.intercept, I'll probably be testing it differently once I get the bin/test script running
[22:42] <gary_poster> cool
[22:42] <lifeless> poolie: is 0 ultimate high or low pri ?
[22:42] <poolie> i will file a bug
[22:42] <rockstar> lifeless, https://code.edge.launchpad.net/~rockstar/launchpad/build-farm-job-constraint/+merge/36219
[22:42] <rockstar> lifeless, I'd be interested in your opinion here.
[22:42] <lifeless> rockstar: I need to pop out to the shops briefly, will look when I return
[22:43] <poolie> it uses the rule that is relevant and has the numerically highest priority
[22:43] <poolie> so 0 is ultimate middle :)
[22:43] <poolie> you could go negative
[22:43] <poolie> but i imagined we would use 0 for the defaults
[22:43] <rockstar> lifeless, ack.
[22:43] <poolie> hello gary_poster, rockstar
[22:43] <gary_poster> hey poolie :-)
[22:43] <rockstar> poolie, hi.
[22:50] <jml> ~30 mins :(
[22:50] <jml> g'night all.
[22:50] <poolie> hi jml! sleep well
[22:51] <poolie> lifeless: i'm trying to work out what the doc/usability bug should be
[22:52] <leonardr> lifeless: fyi, after merging your branch my branch ran ec2 with no test failures, but for some reason the ec2 run failed anyway
[22:52] <leonardr> Tests failed (exit code 1)
[22:52] <leonardr> make: *** [check] Error 1
[22:52] <poolie> well, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/644751
[22:52] <_mup_> Bug #644751: should be easier to tell which flags are active <flags> <Launchpad Foundations:Confirmed for mbp> <https://launchpad.net/bugs/644751>
[22:52] <poolie> feel free to add more
[22:55] <mars> rockstar, poolie, since you are on the topic of feature scopes: the docs don't say how to install a scope or feature for just one test.  Did either of you have an idea about how it could be done?
[22:56] <mars> rockstar, unping
[22:56] <mars> lifeless, that last was meant for you
[22:56] <poolie> i'm just replying to noodles's mail about exactly that
[22:56] <mars> haven't looked today - on lp-dev?
[22:56] <gary_poster> cr3: ah-ha!  You have encountered https://bugs.edge.launchpad.net/ubuntu/+source/python2.6/+bug/621348 !
[22:56] <_mup_> Bug #621348: .pth and .egg-info files in /usr/lib/pymodules/python2.6 are not being processed <python2.6 (Ubuntu):New> <python2.6 (Debian):Unknown> <https://launchpad.net/bugs/621348>
[22:56] <gary_poster> congratulations! ;-)
[22:57] <mars> poolie, ok.  The other thing I was wondering - why do I need a full database to fire up a feature?  Can we just do a simple dict-based controller for that?
[22:57] <cr3> gary_poster: reading and scrutinizing for workaround :)
[22:57] <gary_poster> cr3: :-) workaround I would suggest is to use the packaged eggs.  Would that work for you?
[22:58] <mars> poolie, or some way to install a custom FeatureController that is just a dict :p.  Maybe a bit more with scopes if need be.
[22:58] <gary_poster> sorry, "packaged eggs" was two mistakes in two words cr3
[22:58] <gary_poster> I meant the .tgzs available from PyPI
[22:58] <gary_poster> Or launchpad in this case
[22:58] <poolie> mars istm that for most tests you shouldn't care about the rules and scopes
[22:59] <cr3> gary_poster: packaged eggs just for lazr.restfulclient?
[22:59] <poolie> you just want to say "with active_features([blah, blah, blah])"
[22:59] <cr3> gary_poster: err, "tgz" just for lazr.restfulclient? :)
[22:59] <gary_poster> :-) yeah.  is that acceptable cr3?  I'd actually recommend all the lazr things be from Python source packages (tgzs)
[23:00] <gary_poster> you could do that probably pretty easily
[23:00] <mars> poolie, "with active_features()" - is that documented?
[23:00] <mars> poolie, because I have yet to see it
[23:00] <cr3> gary_poster: I tried that earlier and got something about not being able to find distribution for elementtree, but that might've been because of the wsgi stuff. let me try again real quick
[23:00]  * gary_poster needs to turn into pumpkin, cr3
[23:01] <poolie> mars, that was science fiction
[23:01] <poolie> i'm saying that's what the api should be
[23:01] <mars> lol
[23:01] <poolie> like a famous announcement from our ex-government telco "no email should have been lost during this upgrade"
[23:01] <poolie> yeah, "shoudl"
[23:01] <poolie> *should
[23:02] <cr3> gary_poster: darn, I'll try me best then and try to get some rest even if it doesn't work :)
[23:02] <cr3> Error: Couldn't find a distribution for 'elementtree'.
[23:02] <cr3> crap, no clue where that's coming from
[23:02] <gary_poster> cr3: ack.  Send me an email (and a branch!) and I'll look at it tomorrow morning
[23:03] <gary_poster> let me try
[23:05] <mars> poolie, so Michael's helper is a start.  It would be nice to break the database dependency, but that can be done later
[23:05] <gary_poster> cr3, worked for me
[23:05] <poolie> right
[23:05] <poolie> i'll try to do that in my next slice on it
[23:05] <poolie> got to do some bzr things today
[23:06] <cr3> gary_poster: 1. added lazr.restfulclient-0.10.0 to download-cache; 2. added lazr.restfulclient to eggs under [buildout]; 3. make build?
[23:07] <gary_poster> cr3: http://pastebin.ubuntu.com/498023/
[23:07] <reed|work> bryceh: Why not just fix the link to go to the non-dupe bug?
[23:07] <gary_poster> 8-9: hack to get packages
[23:07] <reed|work> as in, go up the chain
[23:07] <gary_poster> 4-15 also
[23:07] <gary_poster> 14-15 I mean
[23:07] <reed|work> bryceh: and update launchpad with the actual bug
[23:07] <reed|work> rather than the dupe
[23:07] <gary_poster> 23 says :don't get my dependencies from site-packages
[23:07] <gary_poster> 31 is a convenience to get an interpreter to play around with
[23:08] <gary_poster> 41-43 should mean that you can reinstate allow-picked-versions = false
[23:08] <bryceh> reed|work, right that's how I'd *like* to fix it
[23:09] <gary_poster> cr3: argh import still fails
[23:09] <gary_poster> also, it didn't get packages; looking
[23:09] <gary_poster> need to go RSN
[23:09] <reed|work> bryceh: I was just reading your initial commit, which didn't seem like a very good fix ;)
[23:09] <bryceh> reed|work, unfortunately launchpad appears to capture the fact that the watched bug has status DUPLICATE, but afaict does not record what the remote dupe bug was
[23:09] <cr3> gary_poster: at least I'm reassured this is not a trivial problem :)
[23:09] <reed|work> so, can that be fixed?
[23:10] <gary_poster> cr3: well, the debian one isn't.  this is suposed to be
[23:10] <reed|work> well
[23:10] <bryceh> reed|work, aside from fixing a symptom rather than root cause why do you think it is a bad fix?
[23:10] <poolie> john has a big, useful patch stalled
[23:10] <poolie> r
[23:10] <poolie> https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877
[23:10] <reed|work> because launchpad won't be showing the *real* status of the upstream bug
[23:10] <poolie> if i read it, will someone from the lp team join me?
[23:10] <reed|work> which is what this is supposed to be providing
[23:11] <reed|work> it will just be showing the status of some dupe bug that nobody upstream is looking at
[23:11] <jml> poolie, I can try, but can't promise anything this week.
[23:12] <bryceh> reed|work, I think you're jumping the gun a bit.  ;-)
[23:12] <bryceh> reed|work, as I see it there are three possible ways to address the complaint
[23:12] <bryceh> reed|work, two of the three are fairly trivial, and I did implementations of both of those
[23:12] <bryceh> the third, making the bugwatch auto-update, is not as easy as it seems
[23:13] <bryceh> because while we capture the fact that the upstream bug is marked RESOLVED DUPLICATE, we do not capture the identity of the bug it was duped against
[23:13] <gary_poster> cr3: your builout doesn't actually install your software :-P :-)
[23:13] <bryceh> in any case, I have emailed gmb for advice on how to do that third approach, and shown him the other two
[23:14] <cr3> gary_poster: if I can't run the tests, it's a feature that it doesn't actually install :)
[23:14] <gary_poster> lol
[23:14] <bac> mars, gary_poster: lucid_lp builder failed with "Cannot rebuild database. There are 1 open connections."  is that fixable by a forced rebuild?
[23:14] <reed|work> bryceh: where is the code that pulls from bugzilla?
[23:14] <reed|work> like, pathwise or filewise
[23:14]  * reed|work is pulling launchpad
[23:14] <mars> bac, yes, force rebuild
[23:15] <mars> bac, it could take a few tries to clear it
[23:15] <bryceh> reed|work, recall the original complaint was that mozilla was feeling spammed by updates to dupe bugs; that complaint is easy to solve
[23:15] <reed|work> sure
[23:15] <bac> mars, gary_poster: thanks
[23:15] <reed|work> people are also whining about launchpad touching old bugs
[23:15]  * gary_poster just watched, and started to reply
[23:15] <reed|work> that haven't had activity forever
[23:16] <reed|work> but I care less about that
[23:16] <bac> mars:  it just started and says "ETA of 2h 14m".  what is it smoking?
[23:16] <bryceh> reed|work, well like I said that was probably just because we started tracking Importance now
[23:16] <reed|work> bryceh: sure
[23:17] <reed|work> https://bugzilla.mozilla.org/show_bug.cgi?id=597786
[23:17] <reed|work> https://bugzilla.mozilla.org/show_bug.cgi?id=597902
[23:17] <reed|work> see those two bugs
[23:17] <mars> bac, I think that is close to normal now.  Might be the time from the last run?
[23:17] <reed|work> those are complaints people have been having
[23:17] <bryceh> reed|work, heh when my son whines we make a point not to give him what he's whining for so we don't reinforce the behavior ;-)
[23:17] <mars> bac, there is a lot of overhead in there besides running the suite
[23:17] <gary_poster> lol bryceh
[23:18] <bac> bryceh: do you squirt him with water?
[23:18] <reed|work> bryceh, that works, except when he's right.
[23:18] <reed|work> ;)
[23:18] <bryceh> bac, in the bathtub and he loves it ;-)
[23:18] <bryceh> reed|work, anyway just stay tuned, I'm way ahead of you ;-)
[23:19]  * bac just watched the big bang theory "positive reinforcement" episode...
[23:19] <bryceh> bac, lol
[23:20] <reed|work> bryceh, you saw the complaint about launchpad re-adding the link when people remove it, right?
[23:20] <reed|work> especially if it's wrong
[23:20] <bryceh> reed|work, no didn't see that
[23:20] <reed|work> see the two bugs I linked above ;)
[23:21] <bryceh> reed|work, but having just looked at the update code I know why - if the field is blank it updates it
[23:21] <bryceh> reed|work, obvious workaround would be to just put garbage in the field and it won't update.  "NOTHING" would do it
[23:21] <reed|work> wait, which field?
[23:22] <reed|work> you can't put "NOTHING" in a see also field
[23:22] <reed|work> in bugzilla
[23:22] <bryceh> well, any value except blank would prevent launchpad from filling it in
[23:22] <gary_poster> cr3: 21 minutes late, must go!  but this works.  http://pastebin.ubuntu.com/498032/ .  Builds a whole buncha buncha stuff.  Needs more cleanup.
[23:22] <reed|work> yeah, can't put anything but urls, and specific URLs at that
[23:22] <gary_poster> There are some similar probs in your cfg
[23:22] <reed|work> so, that's not really a fix or workaround
[23:22] <bryceh> reed|work, anyway, you'd need to raise this with deryck, I'm just hired gun here :-)
[23:23] <gary_poster> That is, related to not actually building your package
[23:23] <reed|work> sure
[23:23] <gary_poster> Can look tomorrow cr3
[23:23] <cr3> gary_poster: thanks, I'll catchup with you tomorrow!
[23:23] <gary_poster> bye
[23:23] <reed|work> deryck around, or is he gone for the day?
[23:23] <bryceh> reed|work, sounds like there'd need to be some way to record "not bug such-and-such" that would clue launchpad in
[23:23] <bryceh> reed|work, he's probably gone for the day
[23:24] <reed|work> mmm
[23:24] <reed|work> let me think how that could work
[23:26] <rockstar> thumper, I'm going to go for walk.  I'll be back in a bit.
[23:26] <lifeless> mars: what was for me ?
[23:26] <lifeless> leonardr: was there any other data?
[23:27] <mars> lifeless, leonardr's run of the patch
[23:27] <lifeless> ohright
[23:29] <mars> lifeless, oh, the other thing - the API suggesting.  Martin answered my question with artistic fiction - can't easily top that :)
[23:33] <mkanat> gmb: Do you have a Mozilla Bugzilla account?
[23:33] <mkanat> Looks like not.
[23:33] <reed|work> yes, he's graham@canon
[23:34] <mkanat> Ahh.
[23:34] <reed|work> I cc'd him on the first bug
[23:34] <reed|work> not the second one yet
[23:34] <lifeless> poolie: so I'm still confused about the scopes bug thing; its not getting the value back.
[23:35] <lifeless> mars: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/631884
[23:35] <_mup_> Bug #631884: feature flags get out of sync easily <qa-untestable> <Launchpad Foundations:New for lifeless> <https://launchpad.net/bugs/631884>
[23:35] <mars> lifeless, eh?
[23:35] <wgrant> jtv: You should probably warn people that setting a contact address will break all their bugmail.
[23:37] <lifeless> mars: something to be aware of if working up poolies sci fi
[23:37] <mars> right.  I think noodles' patch covers that
[23:39] <mars> lifeless, would the helpers go in lp.testing, lp.testing.features, or lp.features.testing ?
[23:39] <mars> I need some help with the convention here
[23:40] <mars> or on lp.testing.TestCase as a helper method
[23:40] <lifeless> poolie: the memcache code still runs, so I think that the 'disabled' is not propogating correctly.
[23:40] <mars> nah, that wouldn't work for views
[23:41] <mars> lifeless, sorry to bug you with the questions, but you are the Test Engineering Ninja for this shift :)
[23:41] <lifeless> lp.services.features.testing.py
[23:41] <mars> great, thanks
[23:41] <lifeless> lp/services/features/testing.py I mean, obviously ;)
[23:41] <wgrant> jml: Yay, you're killing buildd-slavescanner.txt
[23:43] <jml> wgrant: a letting.
[23:43] <jml> wgrant: a little, I mean.
[23:44] <jml> brain no longer connected to fingers. good night :)
[23:44] <wgrant> Night.