[03:01] <wgrant> Hm
[03:02] <wgrant> BugSubscription.date_created has tzinfo=UTC
[03:02] <wgrant> I thought we mostly used naive UTC datetimes?
[03:02] <wgrant> Hm, it seems to vary.
[03:51] <nigelb> Morning
[03:52] <StevenK> O hai
[03:58] <StevenK> wgrant: What do you think of https://code.launchpad.net/~stevenk/launchpad/db-add-audit-spph and https://code.launchpad.net/~stevenk/launchpad/spph-approved_by-model as two thirds of bug 885739?
[03:58] <_mup_> Bug #885739: queue and override manipulations should have an audit trail <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/885739 >
[04:01] <wgrant> StevenK: Ah, I was going to talk to you about those.
[04:01] <wgrant> StevenK: I think this is another patchwork thing.
[04:02] <StevenK> wgrant: Oh?
[04:02] <wgrant> StevenK: This is the sort of thing that should probably be on PU
[04:03] <StevenK> Right. But it's a bit nasty to get at PU from SPPH, isn't it?
[04:03] <wgrant> But it's difficult because none of this has been designed since 2005, and there's now 5x more of it.
[04:04] <StevenK> I agree PU is probably the better place for approved_by
[04:04] <StevenK> overrride_changed_by belongs on SPPH, and I figured out that the date was utterly pointless since a new SPPH is created.
[04:05] <wgrant> We probably want something like ArchiveAudit which BPPH and SPPH reference.
[04:06] <wgrant> It records all the sponsorship etc. crap, along with the PU if present.
[04:06] <wgrant> It also records the details of the operation, for example the fact that the overrides were changed.
[04:06] <StevenK> Heh, you mean like SPPH.spondor ? :-)
[04:06] <wgrant> Rather than making SPPH even more obese for no good reason.
[04:06] <wgrant> Yes.
[04:06] <wgrant> That totally doesn't belong on SPPH.
[04:06] <StevenK> Agreed
[04:08] <StevenK> wgrant: So, can has mumble about ^ ?
[04:08] <wgrant> I thought Launchpad had a policy against doing Soyuz correctly.
[04:08] <nigelb> lol
[04:09] <wgrant> The idea is that $randomperson just adds more columns to random places in the schema until things sort of work.
[04:10] <wgrant> StevenK: Anyway, can mumble in a few.
[04:10] <wgrant> Just finalising some triggers now.
[04:10] <wgrant> Delicious, delicious PL/pgSQL
[04:10] <StevenK> Haha
[04:11] <nigelb> So, that's what wgrant eats for breakfast. Code.
[04:11] <wgrant> My secret is revealed.
[04:21] <StevenK> wgrant: A few what?
[04:21] <StevenK> :-)
[04:24] <wgrant> Hmm, my window decorations have gone missing.
[04:30] <huwshimi> wgrant: I'm starting to feel like I'm going to need a hardware "unity --replace" button
[04:38] <StevenK> lifeless: O hai
[04:39] <wgrant> huwshimi: About half the time my kernel hangs, but the other half I just Ctrl+Alt+F1 and do it there.
[04:45] <huwshimi> wgrant: Yeah, that seems about the same as me
[05:04] <StevenK> wallyworld_: Would you mind +1ing https://code.launchpad.net/~stevenk/launchpad/kill-spph-ancestor/+merge/94716 ?
[05:04] <wallyworld_> StevenK: np, looking now
[05:06] <wallyworld_> StevenK: so ancestor is never used anywhere? tests or anything?
[05:07] <StevenK> Hmmm, it is referenced in the factory
[05:07] <StevenK> Still digging
[05:09] <wallyworld_> ok, i assume you'll update the branch and then i can +1
[05:12] <StevenK> wallyworld_: Hah, turns out both wgrant and I were wrong.
[05:13]  * StevenK deletes the MP, since it's dangerous to land and would cause us to lose data
[05:13] <wallyworld_> first time for everything
[05:21] <wallyworld_> wgrant: how close is your multipolicy-3 branch to being merged?
[05:22] <wgrant> wallyworld_: -50 minutes
[05:23] <wallyworld_> wgrant: cool. i have a branch that i  need to merge in your changes before i finish
[05:23] <wgrant> wallyworld_: That is, it landed 50 minutes ago.
[05:24] <wallyworld_> ah, i read '-' as '~'
[05:24] <wallyworld_> thanks
[05:24] <wgrant> So did StevenK.
[05:24] <wgrant> Silly northerners.
[05:24] <wallyworld_> we old farts have poor eyesight
[05:41] <wgrant> Hmmmmmm
[05:41] <wgrant> Declarative factory next week, I think.
[05:45] <StevenK> wgrant: Indicies on ArchiveAudit are going to be ... fun
[05:45] <wgrant> Easy enough.
[05:45] <StevenK> Oh?
[05:45] <wgrant> There's only a single date, and everything else is easy.
[05:46] <StevenK> I want an index for every column?
[05:46] <StevenK> Aside from date, that is
[05:46] <wgrant> So, individual indices aren't immensely useful.
[05:46] <wgrant> Indices for individual columns, that is.
[05:47] <wgrant> Postgres can sometimes do a reasonable job by ANDing them together. But generally you'd create indices that satisfy the queries that you want.
[05:47] <wgrant> Which is, in this case, none.
[05:47] <StevenK> I was attempting to think ahead
[05:47] <wgrant> Until we want to run queries over that table, single-column indices on id and the person FKs are what you want.
[05:48] <wgrant> (just enough to satisfy the foreign key constraints in sensible time, since we don't know what sort of queries we want otherwise)
[06:09] <lifeless> StevenK: hi, I'm on leave today; if its urgent please give me a ring, otherwise ping tomorrow
[06:09] <StevenK> lifeless: Tomorrow is fine
[07:18] <StevenK> wgrant: Can I not create a table and add comments to comment.sql in the same patch?
[07:20] <wgrant> StevenK: You can.
[07:20] <StevenK> psycopg2.ProgrammingError: schema "archiveaudit" does not exist
[07:20] <wgrant> You're doing it wrong.
[07:21] <StevenK> Indeed
[07:21] <wgrant> Did you forget to s/TABLE/COLUMN/?
[07:21] <StevenK> Perhaps :-)
[07:22] <StevenK> wgrant: And I suspect we can ignore adding perms onto archiveaudit until we start to use it
[07:22] <wgrant> No
[07:22] <wgrant> The person foreign keys mean that there has to be SELECT and UPDATE on archiveaudit to the person merger.
[07:22] <lifeless> fk's
[07:23] <StevenK> Which runs as launchpad_main?
[07:23] <wgrant> Hell no.
[07:23] <StevenK> I see it
[07:24] <StevenK> lifeless: Go away, you're on leave.
[07:26] <stub> Reviewing PL/SQL code doesn't look any more fun after second coffee.
[07:26] <StevenK> Haha
[07:27] <stub> StevenK, wgrant: For person merge, the tests unfortunately still run as launchpad_main I think, and there is a 'person-merge-job' user or similar that is actually used on prod.
[07:31] <StevenK> That is disappointing.
[07:32] <StevenK> A quick bzr grep agrees, though.
[07:38] <StevenK> Hmmm, is bug searching horrible again?
[07:41] <wgrant> StevenK: No, should be better than usual, for a couple of reasons.
[07:43] <StevenK> wgrant: Keeps timing out for me
[07:43] <wgrant> OOPS ID?
[07:43] <wgrant> Large listings are certainly not snappy, but then the dynamic stuff never has been.
[07:44] <StevenK> wgrant: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-732cfe7bfe2e69be0875af0907fee4e1
[07:45] <wgrant> 2.6s here
[07:47] <wgrant> StevenK: Still happening?
[07:47] <wgrant> I've been idle long enough that I'm on a slave.
[07:48] <wgrant> You're still on the master.
[07:48] <wgrant> Which may be relevant.
[07:48] <StevenK> It just worked.
[07:49] <wgrant> The karma DoS is in progress.
[07:49] <wgrant> May be relevant.
[07:50] <StevenK> Heh
[07:50] <wgrant> (it's something like 2000 writes per second at times)
[07:52] <wgrant> StevenK: Shouldn't archive, distroseries, pocket be NOT NULL?
[07:52] <wgrant> Also date.
[07:53] <StevenK> Good point.
[07:53] <wgrant> And this shouldn't land until we've got code for everything to populate it.
[07:54] <wgrant> So we can actually be sure it fits.
[07:54] <StevenK> Right
[08:53] <adeuring> good morning
[09:01] <mrevell> G'mornin'
[09:20] <wgrant> stub: Thanks.
[09:21] <wgrant> The DISTINCT ON shouldn't be necessary at all IIRC, except that there's no UNIQUE bugsubscription(bug, person) :/
[09:23] <stub> If there are multiple people with multiple results in there, you might get multiple (bug,person) rows intermixed I think.
[09:23] <stub> oic.
[09:24] <wgrant> The join should be unique already, except that the origin table is invalid because of the lack of unique constraint.
[09:24] <wgrant> (and there are violations)
[09:24] <stub> There might have been a time we did allow multiple subscriptions from a person. I wonder if person merge can still create them?
[09:25] <wgrant> I believe that's how they all came about.
[09:25] <wgrant> I suspect it's an oversight rather than a feature.
[09:25] <stub> I'd go with the ORDER BY just in case as this is a temporary trigger
[09:30] <wgrant> stub: Indeed, wasn't suggesting otherwise :)
[09:31] <wgrant> I just added that as a quick hack to workaround the bad data and forgot to make it deterministic.
[09:38] <jelmer> 'morning launchpadders
[09:40] <danhg> Morning jelmer :)
[10:52] <nigelb> HI jelmer!
[12:11] <wgrant> czajkowski: Those bugs are on some project that someone randomly added to launchpad-project.
[12:11] <wgrant> czajkowski: We should get a webops to remove it from the group.
[12:12] <czajkowski> wgrant: context ,ooking at a lotta bugs this morning and trying to work them out
[12:13] <wgrant> Ah, it was nearly two hours ago now.
[12:13] <wgrant> You triaged three bugs on gazungaos
[12:17] <czajkowski> wgrant: nods the kubuntu folks
[12:18] <czajkowski> wgrant: but yes removing it from the group would be good also
[12:18] <czajkowski> thanks sorry being thick, lotta traiging and back and forthh going on this mornign
[12:19] <wgrant> Hm? Not Kubuntu.
[12:19] <wgrant> It's some random project unrelated to Ubuntu.
[14:25] <czajkowski> where does the ubuntu bug pull information from for the twitter feed?
[14:34] <deryck> adeuring, https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
[14:35] <danilos> flacoste, lifeless: hi, I wonder if it would be possible to export a Sprint API function that allows registering people by email address and calls ensurePerson() on that email? we'd want this to integrate better with our summit registration form which already collects a bunch of data about people
[14:46] <abentley> adeuring: lp:~abentley/launchpad/lazr.jobrunner
[15:02] <flacoste> danilos: well, we don't want to add the ability to register people in Launchpad without their confirmation
[15:02] <flacoste> danilos: so that would either need to be limited to a very specific user
[15:02] <flacoste> danilos: or that API should email the user to ask for confirmation
[15:04] <danilos> flacoste, right, understood, thanks (that'd be a a simple solution for our integration of registration form/launchpad/summit), but I guess we'll have to fix summit as well :)
[15:05] <danilos> flacoste, basically, we have a requirement that whoever registers for our conference has a Launchpad account, but we could only get to the point of them having SSO account
[15:05] <danilos> flacoste, we'll have to point them to log into Launchpad before we allow them to register
[15:12] <flacoste> danilos: that's interesting
[15:13] <jml> I'm waiting on Launchpad to acknowledge my recent 'push'
[15:13] <flacoste> danilos: maybe you could add a ensurePersonFromSSO that would create a LP profile for someone with a SSO account
[15:13] <jml> I've been waiting for some time now
[15:13] <flacoste> jml: interesting, i think abentley landed some change to the branch scanner
[15:13] <flacoste> might be related, although i'm not sure if they were deployed
[15:13]  * flacoste checks
[15:14] <flacoste> yep, was rolled out
[15:14] <flacoste> yesterday
[15:16] <abentley> jml: what branch?
[15:16] <jml> abentley: lp:~jml/pkgme-service/directory-already-exists
[15:17] <abentley> jml: So I see pushes from 30 minutes ago, but still "Updating branch".
[15:18] <jml> abentley: yeah, I'm waiting for r73
[15:22] <abentley> jml: looking...
[15:28] <abentley> jml: It appears we were just slow.
[15:28] <jml> abentley: thanks.
[15:48] <abentley> jml: There's been pretty heavy traffic on the branch scanner today.  There was a block of 8 jobs that started at 15:05:10 and finished at 15:10:25.  I'm guessing you pushed in that timeframe.
[15:49] <abentley> jml: The next block was a block of 30 jobs that ran from 15:11:09-15:13:43.
[15:50] <abentley> jml: then a futher block of 13 from 15:14:09-15:17:54.
[15:54] <jml> abentley: ah, ok.
[15:55] <danilos> flacoste, that'd work for us, should we go that route perhaps?
[15:56] <flacoste> danilos: yes, i think so, the complex bit is in finding out if the email address has a SSO account
[15:56] <danilos> flacoste, right, we can't rely on account table anymore
[15:57] <danilos> flacoste, do you have any idea on how we could do that? would we need something on the SSO side as well?
[15:58] <flacoste> danilos: yes, there might be an existing api for this on canonical-identiy-provider
[16:05] <danilos> flacoste, ok, I'll check if there's something along the lines
[16:42]  * czajkowski glares at launchpad and wonders why it has to misbehave! 
[17:18] <nigelb> czajkowski: Remember to ask StevenK about how launchpad is made. he has that long line about everything being held together by strings and jaffa tape.
[20:41] <flacoste> gary_poster: any reason why buildout doesn't use the versions specified in setup.py (vs the one in versions.cfg)?
[20:43] <czajkowski> flacoste: evening, good weekend?
[20:44] <flacoste> hi czajkowski, yes, it was great, went to party at a friend's new appartment on Saturday, how about you?
[20:47] <czajkowski> good thanks, nice weekend went to see a rubgy game, and now working on community council work after dinner
[20:50] <flacoste> nice
[20:51] <czajkowski> yup the weather is actually improving :D
[21:04] <gary_poster> flacoste, not sure, but I think versions.cfg is applied afterwards, so it wins.
[21:05] <flacoste> gary_poster: ah, right, and you usually don't want to pin in setup.py, so that makes sense
[21:32] <wallyworld_> StevenK: wgrant: jcsackett: the trains are not running today and i have to help out my neighbour by driving her kids to school so i'll miss the standup
[21:49] <cr3> hi folks, how do you assign the on call reviewer?
[21:56] <lifeless> flacoste: hi
[21:56] <flacoste> lifeless: hang out?
[21:56] <lifeless> sending you an invite
[21:57] <lifeless> flacoste: it should be in your stream
[21:58] <flacoste> lifeless: you invited my canonical.com account?
[21:58] <lifeless> possibly not :)
[21:58] <flacoste> lifeless: got it
[22:03] <cr3> benji: ^^^ since you're the on call reviewer, ping :)
[22:04] <benji> cr3: we have a schedule, hold on a sec and I'll find it
[22:04] <cr3> benji: thanks, I'd like to adopt the same process in our team instead of inventing our own :)
[22:08] <benji> cr3: the schedule is at https://dev.launchpad.net/ReviewerSchedule; you may also be interested in http://bradcrittenden.net/post/358363191/getting-your-code-into-launchpad
[22:09] <benji> cr3: and this too https://help.launchpad.net/Code/Review
[22:11] <cr3> benji: thanks for all the info, much appreciated!
[22:11] <benji> cr3: my pleasure
[22:26] <wgrant> lifeless: Why do bugtask inserts take 290ms on prod?
[22:26] <wgrant> Is bugsummaryjournal very slow?
[22:28] <flacoste> lifeless: i think your ISP crashed
[22:31] <lifeless> flacoste: bah my adsl
[22:31] <flacoste> lifeless: yep, i need to go, i suggest we resume that conversation tomorrow?
[22:32] <lifeless> wgrant: shouldn't be, is it ?
[22:35] <wgrant> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-6e6b4b29ef635939095468528e92c7ec
[22:40] <lifeless> wonder if the rollup is honkeydory
[22:40] <lifeless> nup 0
[22:40] <wgrant> lifeless: Huh
[22:40] <wgrant> Can you try an EXPLAIN ANALYZE in a txn?
[22:41] <wgrant> See which trigger takes the time.
[22:41] <wgrant> I was worried about my trigger adding 0.4ms sometimes
[22:41] <wgrant> I see that won't be a problem :)
[22:42] <lifeless> if you prep a test I will run it for you
[22:42] <lifeless> today is not a good day
[22:42] <lifeless> wgrant: is our heat logic uncontended yet ?
[22:43] <wgrant> lifeless: maxheat is no longer updated or even calculated, and garbo-hourly is doing nothing.
[22:43] <wgrant> So indeed it should be uncontentious.
[22:44] <wgrant> bugtask only has three triggers, and bugsummary is the only one that seems like it could really do much.
[22:44] <lifeless> is the bug private with a lot of subscribers
[22:45] <wgrant> It's public security.
[22:45] <wgrant> 11 subscribers
[22:45] <wgrant> 9 trillion contexts
[22:45] <wgrant> https://bugs.launchpad.net/ecryptfs/+bug/732628
[22:45] <_mup_> Bug #732628: TOCTOU in mount.ecryptfs_private <kernel-cve-tracking-bug> <patch> <eCryptfs:Fix Released by kirkland> <ecryptfs-utils (Ubuntu):Fix Released by kirkland> <linux (Ubuntu):Fix Released> <linux-ec2 (Ubuntu):Invalid> <linux-fsl-imx51 (Ubuntu):Invalid> <linux-linaro (Ubuntu):New> <linux-lts-backport-maverick (Ubuntu):Invalid> <linux-lts-backport-natty (Ubuntu):Invalid> <linux-lts-backport-oneiric (Ubuntu):Invalid> <linux-mvl-dove (Ubun
[22:46] <wgrant> Like 14 source packages
[22:46] <wgrant> Each with 5 series
[22:46] <wgrant> sigh, kernel team abusing packages
[22:46] <kirkland> holy smokes
[22:48] <lifeless> wgrant: possibly inefficient distro rollup check with each row being in the same distro or something
[22:48] <lifeless> wgrant: should be able to reproduce locally. I suspect a bugsummary query inefficiency
[22:50] <wgrant> lifeless: Also the kernel team abusing Launchpad
[22:51] <wgrant> That bug has 73 tasks :/
[22:51] <wgrant> Maybe I should introduce a limit of 3 package tasks per distro.
[22:52] <wgrant> Would only break the kernel team.
[22:52] <wgrant> But would also fix Launchpad.
[22:53] <elmo> wgrant: how is that "abuse"?
[22:54] <wgrant> elmo: It's an order of magnitude more tasks than Launchpad is designed for, because the kernel is duplicated in 13 source packages.
[22:55] <wgrant> 14, sorry
[22:55] <micahg> wgrant: would break transition bugs as well
[22:56] <StevenK> poolie: O hai. A user reported yesterday that http://pad.lv/nnnnn => works fine; https://pad.lv/nnnnn => 404 , is that known?
[23:02] <poolie> yes
[23:02] <poolie> i guess making it work but with an invalid cert would be a start
[23:04] <wgrant> poolie: Or just get a free StartSSL cert?
[23:04] <wgrant> Not sure if IE likes them, but all non-Windows browsers I've run into too.
[23:04] <wgrant> s/too/do/
[23:04] <poolie> oh, can you?
[23:04] <wgrant> startssl.com
[23:04] <poolie> i guessed that :)
[23:04] <wgrant> Their web UI sucks, but it works.
[23:05] <poolie> is it worth anything?
[23:05] <poolie> i guess the browser vendors have decided there is a modicum of security
[23:05] <wgrant> It's probably more secure than most other CAs...
[23:05] <wgrant> given they all just do hopeless email validation anyway.
[23:05] <wgrant> With the added bonus of being corrupt.
[23:06] <wgrant> Ah, they have an IE logo, so looks like even IE likes them now.
[23:47] <poolie> ok i'll see what i can do
[23:47] <poolie> feel free to file a bug against pad.lv if you wish
[23:49] <timrc> are people able to create distributed distributions? I'd like to create a full mirror of beta1 our developers can use to bootstrap their live-build images