[00:06] <wallyworld_> jelmer: i've just noticed the same thing, don't know what causs it :-(
[00:06] <jelmer> I can reproduce it on both of my machines
[00:06] <wallyworld_> i've just upgraded to oneiric
[00:06] <jelmer> my machines are both on oneiric
[00:06] <jelmer> strangely enough the server logs indicate that the client disconnected suddenly
[00:08] <mwhudson> ssl error?
[00:08] <jelmer> mwhudson: yup
[00:08] <mwhudson> why do we use ssl on a db connection to localhost? :)
[00:08] <cjwatson> it isn't trying to use SSLv2, is it?
[00:08] <wallyworld_> and why has it started failing now? what's changed?
[00:08] <cjwatson> well, actually, that was turned off in natty
[00:09] <cjwatson> but OpenSSL 1.0.0 in Oneiric turned off various other rarely-used bits of SSL
[00:09] <cjwatson> things like MD2 hashing
[00:09] <cjwatson> might be worth checking that
[00:10] <wallyworld_> might explain why lucid hasn't any problems
[00:11] <jelmer> cjwatson: that's an interesting thought
[00:13] <jelmer> cjwatson: that's just libssl0.9.8?
[00:16] <cjwatson> jelmer: well, it's libssl1.0.0 now
[00:16] <cjwatson> there's only a handful of libssl0.9.8 reverse-deps left, and none that I think have anything to do with Launchpad
[00:21] <jelmer> it seems unlikely that's the culprit
[00:21] <jelmer> I have libssl1.0.0 1.0.0d-2ubuntu2, which was uploaded on aug 15; the breakage started at most two or three days ago
[00:22] <cjwatson> well, it could have been some dependency switching over to it (they're different sonames), but yes, two or three days ago does make that a bit unlikely
[00:25] <jelmer> hmm
[00:26] <jelmer> I'll have a closer look tomorrow, thanks for the hints
[00:26] <jelmer> wallyworld_: if you do stumble upon a solution.. please let me know :)
[00:26] <StevenK> jelmer: Can you explain https://code.launchpad.net/~loggerhead-team/loggerhead/1.18/+merge/74532 ? It's full of conflict markers.
[00:26] <wallyworld_> jelmer: will do. i'm currently looking at something else though
[00:29] <jelmer> StevenK: argh, fail. I'll set it back to wip for now
[00:30] <jelmer> the trunk *packaging* branch seemed to merge 1.18 just fine for some reason, looks like 1.18 and trunk don't :(
[00:43] <wallyworld_> jelmer: i replaced host with hostnossl in pg_hba.conf and it works for now
[00:44] <wgrant> Odd, it's working fine for me.
[00:45] <wgrant> But it's in a container.
[00:45] <wallyworld_> wgrant: i think lucid is ok
[00:45] <wgrant> Container is up to date, host is not... maybe will upgrade the host too.
[00:45] <wgrant> No, this is an oneiric container.
[00:45] <wallyworld_> something seems to have changed wrt ssl that has broken things, so if you upgrade, be careful
[00:46] <wallyworld_> gah. my "fix" didn't work a second time
[00:47]  * wgrant upgrades the host.
[01:04]  * StevenK stares at Thunderbird
[01:04] <StevenK> "Canonical has 21524 new messages."
[01:04] <StevenK> OMGWTFBBQ?!
[01:16] <wallyworld_> StevenK: that's in the staging mailbox?
[01:17] <StevenK> wallyworld_: No, my Canonical mailbox
[01:17] <wallyworld_> oh. that's a shitload of messages then
[01:18] <StevenK> It was telling lies, but it was still a little shocking
[01:27] <G> 21.5k new messages, ouch
[02:28] <LPCIBot> Project db-devel build #849: FAILURE in 4 hr 12 min: https://lpci.wedontsleep.org/job/db-devel/849/
[02:29] <wgrant> Erk
[02:30] <wgrant> Ah.
[02:30] <wgrant> legit failure.
[02:30] <wgrant> Merge issue.
[02:30]  * wgrant enfixorates.
[04:20] <nigelb> Oh. I may have gotten a branch reviewed but forgotten to ask to land
[04:20] <StevenK> nigelb: Which?
[04:20] <nigelb> https://code.launchpad.net/~nigelbabu/launchpad/font-fixes-787798/+merge/74492
[04:21] <StevenK> I wonder if that's totally pointless to run through ec2
[04:22] <nigelb> It is.
[04:22] <poolie> o/ nigel, stevenk
[04:22] <nigelb> Morning poolie!
[04:22] <StevenK> O hai
[04:23] <nigelb> Oooh, the Ubuntu font thing landed. It looks good.
[04:23] <jtv> And while we're at it: hi Nigel, hi antipodeans!
[04:23] <nigelb> haha
[04:23] <StevenK> Yeah, we deployed early AU morning
[04:24] <nigelb> \o/
[04:25] <jtv> If I may interrupt briefly… is anyone willing to review this soyuzzy branch?  Julian said he would yesterday but evidently he didn't get around to it, and I've got other work building on it: https://code.launchpad.net/~jtv/launchpad/bug-832647/+merge/74380
[04:25] <StevenK> % df -h /home | tail -n 1
[04:25] <StevenK> /dev/mapper/sys-home   46G   42G  2.1G  96% /home
[04:25] <StevenK> Hmmmm
[04:26] <nigelb> what's /dev/mapper? lvm?
[04:27] <StevenK> Yeah, LVM
[04:27] <StevenK> Well, strictly, it's device-mapper, so could be LVM or something else than makes use it
[04:28] <poolie> StevenK: you're almost done!
[04:28] <StevenK> Hah
[04:29] <StevenK> I still have 75G unallocated in the VG, so I could just grow /home ...
[04:32] <nigelb> How hard is bug 88545. Is it even possible to do for someone without acces to the db?
[04:32] <_mup_> Bug #88545: Abolish the "statusexplanation" database field <lp-bugs> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/88545 >
[04:34] <StevenK> It's a DB patch
[04:34] <poolie> nigelb: you need to make a patch that changes the db but you don't need access to the db to write it
[04:34] <StevenK> But it may take postgres more than 2.5 seconds to perform ...
[04:34] <poolie> probably the first thing is to just grep for statusexplanation and see if anything uses it at all
[04:34] <poolie> eg to remove it from the activity log
[04:34] <nigelb> Ah
[04:35] <nigelb> do I need db-devel setup?
[04:35] <nigelb> (that seems to be the branch where all db stuff happens)
[04:36] <StevenK> So to remove it from the activity log, no, that can probably just land.
[04:36] <StevenK> You want to make sure the model and interface no longer reference it
[04:36] <StevenK> And then you write *just* a db patch to ALTER TABLE DROP COLUMN
[04:36] <nigelb> Okay :)
[04:37] <nigelb> Graduating to the bugs not marked easy or trivial :D
[04:37] <StevenK> The drop column might perform poorly -- I suggest you talk to stub when he surfaces
[04:37] <nigelb> Yeah, I think so as well.
[04:37] <StevenK> But the first two steps should be easy enough
[04:37] <poolie> i think you get a badge for fixing an mpt bug too :)
[04:38] <poolie> if you haven't already
[04:38]  * StevenK fixed a few at the Thunderdome
[04:38] <StevenK> 'a moment ago' is my fault
[04:38] <poolie> i think i have too
[04:39] <nigelb> I've fixed way too many mpt bugs already
[04:39] <wgrant> StevenK: column dropping is cheap.
[04:39] <wgrant> StevenK: The rows don't get rewritten, the column just gets ignored.
[04:39] <wgrant> The next time the row moves, it will be shrunk.
[04:40] <StevenK> Does VACUUM clean it up?
[04:40] <wgrant> Possibly not entirely.
[04:40] <wgrant> But it's not important.
[04:41] <wgrant> It only takes a bit of disk space, and it's not going to be a truly massive column.
[04:41] <StevenK> It's still used, so that has to go.
[04:42] <wgrant> Yes.
[04:43] <jtv> Still want a reviewer for a soyuzzy branch!  Blocking me a little and reviewer didn't get around to me yesterday: https://code.launchpad.net/~jtv/launchpad/bug-832647/+merge/74380
[04:45] <wgrant> jtv: Interesting tactic to teach the dominator about deletion...
[04:45] <wgrant> (looking)
[04:46] <jtv> wgrant: "interesting" as in "cleverly unexpected," or "interesting" as in "oh my God what were you thinking"?  :-)
[04:46] <jtv> Thanks btw.
[04:46] <wgrant> A combination.
[04:46] <wgrant> In the Ubuntu case I'd prefer a crash over a deletion.
[04:47] <jtv> Crashing shouldn't be hard.
[04:48] <jtv> Anyway, that's for later: I left Ubuntu domination in a state where you don't get deletions.
[04:49] <wgrant> I'd prefer it was for now. Domination has always been very fragile -- I've spent today diagnosing issues surrounding it, with a production incident caused in part by a bad refactoring of the dominator that I made and fixed last year.
[04:50] <wgrant> With a big change like this, I'd really prefer you stick an assertion in there so breakage doesn't go unnoticed.
[04:51] <jtv> What would I assert though?  distro_name != 'ubuntu' or pubs[0].sourcepackagerelease.version == pubs[0].sourcepackagerelease.version?
[04:52] <wgrant> I don't know. But gina and archivepublisher currently use dominator to do different things, so they should probably run it in different modes.
[04:52] <wgrant> The dominator should never delete anything in a Soyuz-native archive.
[04:52] <wgrant> Only for gina.
[04:52] <wgrant> It will cease to be Ubuntu-specific this year.
[04:53] <jtv> Wait, now I'm completely confused.  What are you saying is currently Ubuntu-specific?
[04:53] <jtv> Not gina, obviously,
[04:53] <jtv> and not the dominator, obviously,
[04:53] <jtv> so what will cease to be Ubuntu-specific?
[04:53] <wgrant> When I said "In the Ubuntu case", I really meant "In the Soyuz-native case"
[04:53] <wgrant> Currently Soyuz-native archives are Ubuntu-specific, but they will cease to be soon.
[04:54] <jtv> Okay, to prevent further confusion, could you re-state with that mistake fixed?
[04:54] <jtv> Gina will cease to be specific to Soyuz-native archives this year?
[04:55] <wgrant> gina is by definition not used for Soyuz-native archives.
[04:55] <jtv> So what will cease to be specific to Soyuz-native archives this year?
[04:55] <wgrant> Nothing. Soyuz-native archives will cease to be specific *to Ubuntu*.
[04:55] <wgrant> I said before that stuff was specific to Ubuntu.
[04:55] <wgrant> But I really meant specific to Soyuz-native archives.
[04:56] <wgrant> In particular, the dominator should never call requestDeletion on a publication in a Soyuz-native archive.
[04:56] <wgrant> It should instead crash, as that case doesn't make sense.
[04:58] <jtv> Well the algorithm I've got here (the part that gina bypasses, so that's the "different mode" you referred to above) is such that the deletion case just can't happen.  It's the what-do-we-do-now answer—the one you wanted, I should add—for the newly possible case in gina only.
[04:58] <jtv> How we may extend it later to make that case possible for the publisher's domination is a later concern.
[04:58] <wgrant> Sure, it shouldn't be able to happen.
[04:58] <wgrant> But I want the code to ensure that it can't.
[04:59] <wgrant> Because nature finds a way.
[04:59] <wgrant> We've been bitten before by things like supersede() working on a deleted publication. Other code breaks, calls methods in bad ways, and they do things that nobody ever expected.
[04:59] <jtv> Okay, how would the assertion check for a Soyuz-native archive?
[05:00] <wgrant> dominatePackage will need to know in what mode it is being called.
[05:00] <wgrant> By _dominatePublications or that new thing.
[05:01] <wgrant> Because it should never call requestDeletion when it's called by _dominatePublications.
[05:01] <wgrant> No, I don't know what to call the argument :(
[05:02] <jtv> I don't think it makes any sense to pass a mode argument just to enable an assertion that, essentially, the caller also passed the expected value for another argument.
[05:03] <wgrant> I guess.
[05:03] <wgrant> anyway. dominate_imported_source_packages looks like it's only going to dominate sources that are still named in the source archive's indices.
[05:03] <wgrant> So it won't actually catch deletions, will it?
[05:03] <wgrant> Because they'll no longer be in the indices at all.
[05:03] <jtv> That's for my follow-up branch.
[05:03] <wgrant> Ah.
[05:04] <jtv> I've already got most of the code here; it works out to be quite elegant.
[05:04] <wgrant> Indeed, this has turned out pretty well, I think.
[05:04] <jtv> Especially in the way it lets us handle migration.
[05:04] <wgrant> Yes. So I guess the first run will sort out everything that's not deleted... I think that looks OK.
[05:05] <jtv> The new code iterates over all package names that are published in the series/archive/pocket, and then get()s the list from gina's src_map.
[05:06] <wgrant> Ah. I was thinking you'd have to union, but of course this is done after everything is imported.
[05:06] <jtv> *In the transitional code*, if it's not in there, it finds the latest version (reusing otherwise useful bits of the dominator) and passes that as live_versions.
[05:06] <wgrant> So the DB set is fine, indeed.
[05:06] <wgrant> Yup.
[05:06] <jtv> *Once transition is complete*, I'll remove that code and then the get() will have [] as a default value.
[05:07] <jtv> The really great thing about it is that it requires no code of any real complexity or intimacy, except stuff from the dominator that we can reuse.  Some of it is private, but who cares for explicitly temporary code?
[05:07] <wgrant> Yep.
[05:08] <StevenK> Oh, RARGH
[05:08] <StevenK> nigelb: Still here?
[05:08] <wgrant> I would appreciate a comment in dominatePackage stating that deletion should never happen in native domination, as the live publication is always first. But you have me convinced that the assertion is not required.
[05:11] <StevenK> Thank you for forgetting my session totally, Firefox
[05:12] <jtv> wgrant: I agree with the idea of a comment, but this policy choice falls above dominatePackage's pay grade.  It should be in _dominatePublications, where the choice is made that leads to this.
[05:13] <wgrant> I know it's not really appropriate for dominatePackage, but with a conventional understanding of domination the code makes no sense.
[05:20] <jtv> wgrant: I'm in the process of writing docstrings, with a comment in _dominatePublications pointing out how the mechanism enforces the policy.
[05:21] <wgrant> jtv: Thanks.
[05:22] <wgrant> Approved.
[05:22] <jtv> \o/
[05:22] <jtv> Thanks
[05:22] <jtv> Now if only ec2 would work for me.  Perhaps I should give it another try.
[05:23] <wgrant> Worked fine for me this morning.
[05:24] <StevenK> Still confused :-/
[05:24] <StevenK> But Eventbug helped a little
[05:31] <nigelb> StevenK: yeah
[05:31] <StevenK> nigelb: Compounded by testfix!
[05:31] <StevenK> But your branch has landed
[05:31] <nigelb> haha
[05:31] <nigelb> I have great luck!
[05:32] <nigelb> \o/
[05:32]  * StevenK ponders asking for buildbot to be set on fire.
[05:37] <nigelb> StevenK: need help burning it? :D
[05:38] <StevenK> Haha
[05:38] <StevenK> I need help with JS, I'm so confused
[05:40] <wallyworld_> StevenK: i need to go to soccer soon, but can i help with js?
[05:41] <StevenK> wallyworld_: I'm trying to figure out what JS is fired when I hit a link
[05:41] <wallyworld_> StevenK: normally you would register an onclick handler
[05:41] <StevenK> <a class="sprite modify remove js-action" href="#" style="">unsubscribe from this bug</a>
[05:41] <StevenK> No onclick
[05:42] <wallyworld_> StevenK: there is one set up - but it's done in js whe nthe page loads
[05:42] <wallyworld_> the href="#" means that an onclick wil be used
[05:42] <nigelb> But doesn't that mean there's no fallback in case of disabled JS?
[05:43] <wallyworld_> probably, but we require js for lp now
[05:43] <StevenK> cewrapper.fire(Event.getEvent(e, el, compat || false [05:43]  * StevenK blinks
[05:43] <wallyworld_> StevenK: try looking in bugtask_index.js or bug_subscription_portlet.js
[05:44] <wallyworld_> i think one or both of those have methods which run in the onload callback to set up the links
[05:45] <StevenK> lib/lp/bugs/javascript/subscription.js looks very related
[05:45] <StevenK> But I have no idea how to find the onclick handler function for the link so I can trace it
[05:45] <wallyworld_> StevenK: it's bug_subscription_portlet.js. see it's make_link() method to set the attributes on the link as you posted above
[05:46] <wallyworld_> nigelb: the link does have a fallback - the js sets the href="#"
[05:46] <wallyworld_> StevenK: let me have a quick look
[05:46] <nigelb> wallyworld_: Ah! :)
[05:47] <wallyworld_> StevenK: search for link.on('click'
[05:47] <wallyworld_> there's a few of those for the mute link, the subscribe link etc
[05:47] <StevenK> wallyworld_: The page I'm on is https://bugs.launchpad.dev/product-name-989062/+bug/16/+subscriptions
[05:47] <_mup_> Bug #16: "Swedish" and "Swedish (Sweden)" should be the same language <lp-translations> <Launchpad itself:Fix Released by daf> < https://launchpad.net/bugs/16 >
[05:48]  * wallyworld_ looks
[05:48] <StevenK> I know that doesn't help you much, but it isn't the bug page
[05:48] <wgrant> Oh, that's not the subscriptions portlet.
[05:48] <StevenK> Exactly
[05:49] <StevenK> And Firebug's script tab isn't being very handy about pointing out where the JS is hiding
[05:50] <wallyworld_> StevenK: i don't think you would normally get to that page except by url hacking
[05:50] <wallyworld_> but it is the subscriptions portlet i think, put not rendered in a portlet
[05:50] <StevenK> Huh? I followed a link to get to that page!
[05:51] <StevenK> The "Edit bug mail" link
[05:51] <wallyworld_> StevenK: oh ok. anyway see the bug-subsctipion-list.pt
[05:52] <wallyworld_> it loads the bug_subscription_list.js
[05:52] <wallyworld_> which is the same js as used for the subscription portlet
[05:52] <wallyworld_> StevenK: i have to run to take the kid to soccer but will check back in 30 minutes or so
[06:03] <StevenK> Oh god, all of the JS is in launchpad.js, isn't it
[06:04] <StevenK> All 100,000 lines of it
[06:04] <lifeless> isn't that a build product?
[06:04] <nigelb> StevenK: yup
[06:04] <StevenK> Yes, but it's the JS the browser sees
[06:04] <StevenK> Whereas the JS we edit is split out
[06:04] <nigelb> Its fun using firebug.
[06:23] <nigelb> StevenK: found it yet? :)
[06:29] <nigelb> wgrant / StevenK: Do you both have HE tunnels?
[06:31] <wgrant> We use AARNet's tunnel broker.
[06:31] <wgrant> It's a little closer :)
[06:36] <nigelb> heh
[06:40] <StevenK> I'm quite happy with it
[06:40]  * ajmitch wonders when lp & *.ubuntu.com can be accessible on v6
[06:41] <wallyworld_> StevenK: how's the js stuff?
[06:41] <StevenK> wallyworld_: Crappy
[06:41] <StevenK> Giving up for today
[06:41] <wallyworld_> need any more help?
[06:41] <wallyworld_> ok
[06:41] <StevenK> wallyworld_: I might grab you inappropiately after the stand-up
[06:41] <wallyworld_> oooh. promises, promises
[06:41] <nigelb> BWAHAHA
[06:42] <nigelb> Should I or should I not screenshot.
[06:50] <jtv> nigelb: the way I see it, this could be your retirement money.  And then again, it could be your reason for not reaching retirement age.
[06:51] <nigelb> jtv: I would much rather prefer using it in a presentation. So, I'm leaning to the second option.
[06:52] <jtv> “Not screenshot”?
[06:52] <nigelb> Screenshot and use in a presentation
[06:52] <nigelb> wgrant: do you have a minute to clear up a confusion in the ipv6 wiki page?
[06:53] <nigelb> It says "gksudo gedit /etc/networking/interfaces", in lucid its /etc/network/interfaces. On oneiric do you have networking instead?
[06:54] <jtv> IIRC it's always been /etc/networking/interfaces
[06:54] <jtv> (and by "always" I mean "going back to Debian a decade ago"—I don't know much more than that really)
[06:54] <wgrant> It's always been /etc/network/interfaces
[06:55] <wgrant> As long as I've been using Debian, which is like 2002.
[06:55] <jtv> Ah.  Tab completion has spoiled me.
[06:55] <jtv> And somehow admins who don't seem to mind this keep refusing to set up tab password completion.  It's not fair.
[06:55] <wgrant> Heh
[06:56] <nigelb> ok, so the wiki is lying.
[06:56] <jtv> BTW my having been using Debian for longer than wgrant comes as a bit of a shock.
[06:56] <jtv> My using Debian for longer than wgrant can walk, that I would have believed.  But this…
[06:56] <nigelb> well, he should be old enough to read before he uses a computer...
[06:57] <jtv> Good point.
[06:58] <wgrant> I sadly used Windows until 2001 :(
[06:58] <nigelb> No buffer space available?
[06:58] <nigelb> GAH. No ipv6 yet for me.
[06:59] <nigelb> wgrant: I used Windows until 2007. Windows Vista for a year too (yeah, *stab* *stab* *stab*)
[07:04] <nigelb> Lunch time! Laters folks.
[07:13] <wgrant> Hmm, no stub yet :(
[07:16] <wgrant> Morning stub.
[07:16] <stub> Morning
[07:17] <wgrant> stub: We snuck a librarian deployment through without downtime earlier, so everywhere is 13891 except germanium's poppy and cocoplum.
[07:17] <wgrant> Hopefully that is all the fixes we need.
[07:18] <stub> It is all the fixes we know we need in any way :-)
[07:18] <wgrant> Right.
[07:19] <stub> So if mthaddon has time when he gets here or spm is free, we can kick the tires.
[07:20] <wgrant> stub: My zopeless destruction branches get rejected by the devel database/schema check :(
[07:20] <stub> With luck you can land it on devel later today. Tests pass?
[07:20] <wgrant> Yup, all three went through ec2 overnight.
[07:21] <wgrant> Are we going to lift the restriction?
[07:21] <wgrant> Since otherwise we're going to be doing a lot of manual merging.
[07:21] <jtv> wgrant: I just realized we never did make Gina create Published publication records.  Still all Pending.  So need to change the code for that as well, _and_ update the database.
[07:21] <stub> I like having it as a safety net, but I don't see the point of having be so vigorously enforced.
[07:22] <wgrant> jtv: We do, but it's not critical.
[07:22] <wgrant> jtv: Since your new dominator method finds everything that's active.
[07:22] <wgrant> Not just published.
[07:22] <jtv> wgrant: errrr
[07:22] <jtv> I stuck to the logic that was already there, which looked for published.
[07:23] <wgrant> + self._composeActiveSourcePubsCondition(distroseries, pocket))
[07:23] <wgrant> Is that active, or published?
[07:23] <jtv> It's published.
[07:23] <wgrant> Heh.
[07:23] <jtv> The dominator tends to say "active" when it means "published."  :(
[07:24] <jtv> But let me just double-check, because we had the confusion in gina before.
[07:24] <wgrant> stub: So, I guess we should actually try it tonight...
[07:24] <jtv> Yup, published.  Not active.
[07:24] <stub> wgrant: now if I can sucker hloeung into doing it
[07:25]  * hloeung logs off... right.... now.... 
[07:28] <rvba> StevenK: Hi, I'd like to ask you a question about the creator field of spph.
[07:29] <rvba> It was introduced by a branch you created to fix bug #684101.
[07:29] <_mup_> Bug #684101: Add an ancestor column to SPPH <derivation> <lp-soyuz> <qa-untestable> <Launchpad itself:Fix Released by stevenk> < https://launchpad.net/bugs/684101 >
[07:29] <wgrant> rvba: It and ancestor were never used.
[07:30] <rvba> Indeed, Julian an I took a look at the db and it's None. (besides, copyTo sets it to None)
[07:31] <rvba> wgrant: StevenK I'd like to use it for real to track copies of spph. Any objection?
[07:32] <wgrant> That was the intention of creator, so do it!
[07:32] <wgrant> It was added alongside ancestor mostly because it was convenient.
[07:32] <wgrant> And ancestor then became redundant; we examine changelogs instead.
[07:32] <rvba> Okay great, this will save me a db patch!
[07:33] <rvba> wgrant: Thanks.
[07:33] <wgrant> rvba: Not that that is a problem.
[07:33] <lifeless> stub: wgrant: landing schema changes on devel? I'd suggest needing a [schema] tag in the commit, but perhaps that wouldn't actually help.
[07:33] <wgrant> lifeless: Possibly, yes.
[07:33] <wgrant> lifeless: If you're not watching #-ops, we're about to do the first test.
[07:33] <lifeless> I'm not here :)
[07:34] <lifeless> safety net off, free falling :)
[07:35] <lifeless> wgrant: someone should tweet :)
[07:35] <wgrant> Once we're confirmed that it's going ahead, yep.
[07:35] <stub> lifeless: something like that, yer. Although I hate overloading the commit message with metadata.
[07:37] <lifeless> will need a pqm patch if we want it, but htats not as scary as some folk think :)
[07:38] <adeuring> good morning
[07:42] <LPCIBot> Yippie, build fixed!
[07:42] <LPCIBot> Project db-devel build #850: FIXED in 4 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/850/
[07:45] <rvba> First day as OCR, allenap is off today so jtv has kindly accepted to be my mentor today.
[07:46] <jtv> “Soft target.  Fire away!”
[07:46] <rvba> :)
[07:50] <wgrant> jtv: That is a very long XXX comment!
[07:51] <wgrant> jtv: Are you going to land this before we do the code+data fixes for Pending->Published?
[07:52] <jtv> wgrant: probably, unless it turns out to be inconvenient w.r.t. how we update the legacy data.
[07:53] <jtv> As long as Gina doesn't get to observe the Pending→Published change in an unnatural order, it shouldn't make much difference AFAICS.
[07:53] <wgrant> Indeed.
[07:53] <jtv> About the worst I can imagine for that scenario is intermediate, but more-or-less-accurate, supersededby links.
[07:54] <wgrant> jtv: Why are you using _sortPackages instead of sorted(..., cmp=generalization.compare), as you did in dominatePackage?
[07:54] <wgrant> You should only have SPPHs for a single name, so _sortPackages isn't needed.
[07:54] <jtv> Just because it gets a little less intimate with the data.
[07:55] <jtv> Matter of taste, really, no more.
[07:55] <wgrant> k
[07:56] <wgrant> Approvalated.
[07:56] <jtv> Great, thanks.  We're really going through them at a clip now.
[07:56] <jtv> Which is good, because I once again gave Julian a "done by the end of this week" estimate.
[07:57] <jtv> Hmm I just realized though: with these changes, the new source file I added to gina ought to be called dominate.py, not retire.py
[07:58] <wgrant> Probably.
[07:59] <jtv> And done.
[08:22]  * mpt awards nigelb his "fixed an MPT bug" badge: (╯°^°)╯︵{FAMPTB}
[08:25] <mrevell> heh
[08:31] <nigelb> haha
[08:31] <nigelb> I should get that on a t-shirt.
[08:31] <nigelb> Next UDS I attend, I'll do that :D
[08:34] <G> rvba: welcome to reviewing :)
[08:35] <rvba> G: ;)
[08:35] <G> here have a look at this patch that removes all the code.... ;)
[08:38] <nigelb> G: That sounds like StevenK's branches :P
[08:40] <nigelb> stub: Hi
[08:40] <G> nigelb: haha sounds about right :)
[08:41] <nigelb> stub: I was asked to run bug 88545 by you. Specifically the bit that requires a db patch
[08:41] <_mup_> Bug #88545: Abolish the "statusexplanation" database field <lp-bugs> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/88545 >
[08:42] <stub> nigelb: I can't look right now - deployment stuff underway. Should be able to check it out within the hour though.
[08:42] <nigelb> stub: sounds good
[08:53] <cjwatson> [6~[6~[6~[6~[5~/wg 62
[08:53] <cjwatson> GAH
[08:53] <nigelb> heh
[09:14] <nigelb> GAH. Bad thing about working from home - telemarketeers knocking on the door.
[09:15] <wgrant> Telemarketers... on the door?
[09:15] <nigelb> Well, wrong word.
[09:15] <G> wgrant: I was just going to make that point
[09:15] <nigelb> The door-to-door salesmen
[09:15] <G> but it was pretty obvious that we all knew what the other Nigel meant :)
[09:15] <ajmitch> parasites?
[09:16] <nigelb> I guess you could call them that.
[09:19] <G> one advantage of living up a 100m driveway and all that, about the only door-to-door thing we get is various churches/religous ones, and the occasional one that does things like door-to-door sales of aerial photography etc
[09:24] <bigjools> Same here!
[09:25] <bigjools> last time I had some religious dudes show up, I squirted them with "holy water" and brandished garlic
[09:26] <lifeless> ttp://hawkersnotice.com/
[09:27] <nigelb> bigjools: heh
[09:27] <nigelb> lifeless: Its not linked! thedoghousediaries.com/?p=3003
[09:28] <nigelb> Oooh,that is good stuff.
[09:29] <nigelb> Amazon has "11.6 seconds mean time between deployments"... what in the world.
[09:29] <lifeless> lots of focused services
[09:30] <nigelb> Is that where the service oriented architecture is leading Launchpad to?
[09:30] <lifeless> yes
[09:30] <nigelb> excellent!
[09:31] <lifeless> The goal is that all commits to trunks are deployed on their own, without batching, and that unrelated things are separate services with narrow contracts
[09:32] <stub> Or it just means serialized deployments to lots and lots of hosts...
[09:32] <nigelb> unrelated things?
[09:33] <lifeless> nigelb: librarian vs codehosting vs group management vs build farm vs ...
[09:34] <nigelb> ahhh, right
[09:35] <nigelb> How does lp deploy now? I know its batched etc. But is it a click to deploy?
[09:35] <lifeless> not quite but close
[09:38] <jtv> Any reviewers in the house?  https://code.launchpad.net/~jtv/launchpad/bug-844577/+merge/74568  ← bigjools maybe, since you didn't get around to my bigger branch yesterday?
[09:39] <nigelb> The reason I ask is, would making each commit deployed on their own cause more work than now?
[09:39] <bigjools> jtv: sorry, gotta sort out a prod issue
[09:39] <jtv> Ah of course, sorry,
[09:39] <jtv> —kept that in a different context
[09:40] <jtv> Anyone else?  https://code.launchpad.net/~jtv/launchpad/bug-844577/+merge/74568
[09:41] <lifeless> nigelb: it always will
[09:41] <lifeless> nigelb: the question is, does the improved accuracy in dealing with fallout and omgs gain more than the cost.
[09:42] <nigelb> Okay, yeah. That's a good point.
[09:43] <nigelb> Also, fail whale for Launchpad would be nice ;)
[09:43] <ajmitch> LP shouldn't need it :)
[09:43] <lifeless> nigelb: patch it up
[09:43] <lifeless> nigelb: I'd love a nicer OOPS page
[09:43] <ajmitch> a rocket exploding?
[09:43] <lifeless> nigelb: and OOPS for ajax requests
[09:44] <nigelb> lifeless: Oh, OOPS for javascript?
[09:44] <nigelb> Have you seen this -> errorception.com
[09:44] <lifeless> nigelb: ajax get OOPS ids in the header of the reply
[09:44] <nigelb> http://errorception.com <-- clickable.
[09:44] <lifeless> nigelb: but the error is shown nastily to the user, not tastefully
[09:45] <nigelb> That would be nice to improve, yes.
[09:45] <nigelb> ajmitch: Rocket exploding OOPS page would be nice.
[09:46] <ajmitch> nigelb: that'd just be an artwork change
[09:46] <lifeless> nigelb: u1 has a form that can be POSTed to by javascript that fails.
[09:46] <lifeless> nigelb: we just need the same for LP, rather than a 3rd party service.
[09:46] <nigelb> lifeless: I'm guessing the code for the u1 page isn't open source?
[09:46] <lifeless> nigelb: we can't use a 3rd party service without some very careful legal stuff, because we have non-public data in js contexts.
[09:47] <lifeless> nigelb: no, but the js side of it is visible :) its a django stack not zope
[09:47] <nigelb> Every page has a form that javascript posts to?
[09:48] <nigelb> In caes of errors..
[09:48] <lifeless> no there is one form for all errors
[09:48] <nigelb> Ah.
[09:48] <nigelb> hrm, how do I force an error from u1.
[09:48] <ajmitch> this openid thing is puzzling me now
[09:48] <lifeless> ask rockstar about it :)
[09:49] <nigelb> Does u1 web team have a different channel or all in one channel.
[09:49] <nigelb> I shall poke rockstar at a more favorable time, when he's awake.
[09:49] <lifeless> well, not on freenode :)
[09:49] <nigelb> GAH.
[09:49] <nigelb> oh. I haven't looked at Ubuntu one website in a while.
[09:50] <nigelb> Its...wow
[09:54] <nigelb> lifeless: Nope, my firebug skills don't show me anything. Need to ask rockstar.
[09:56] <bigjools> wgrant: we're getting rabbitmq 2.6.0 in oneiric \o/
[09:56] <bigjools> it's got HA clustering
[09:56] <wgrant> bigjools: Oneiric? Nice.
[09:56] <wgrant> Well, yes.
[09:56] <wgrant> It has active-active.
[09:57] <wgrant> It requires some restrictions, though.
[09:57] <bigjools> I'd like to say it was my doing, but it's a requirement for OpenStack
[09:57] <wgrant> bigjools: It's not quite a trivial update, as the PID handling has changed. But it's like 5 lines of initscript that need adjusting.
[09:57] <wgrant> Ahh.
[09:58] <wgrant> bigjools: I guess I should update the plugins for 2.6.0 at some point, then.
[09:58] <bigjools> wgrant: yes please ;)
[09:59] <nigelb> we don't yet use rabbit heavily, do we?
[09:59] <nigelb> I thought the only place I saw it was the new sync stuff
[09:59] <wgrant> nigelb: We don't use it at all yet.
[09:59] <wgrant> The first use is MP diff updating.
[09:59] <nigelb> OH YES
[09:59] <nigelb> PLEASE
[09:59] <wgrant> It is implemented.
[09:59] <wgrant> Just not deployed.
[10:00] <nigelb> Ah. That will make a lot of people very happy.
[10:01] <bigjools> coming soon to a Launchpad near you
[10:01] <wgrant> "soon"
[10:01] <bigjools> we start work on it next week
[10:01] <bigjools> 2 weeks will be enough
[10:01] <nigelb> Oh, btw. What does the tag bug-columns mean?
[10:01] <wgrant> nigelb: That's the next feature.
[10:01] <wgrant> nigelb: Customisable bug listings.
[10:02] <wgrant> nigelb: So you can eg. show assignee in search results.
[10:02] <nigelb> \o/
[10:02] <ajmitch> that sounds useful
[10:02] <bigjools> once that's done I want to replace crontabs with rabbit queues
[10:02] <wgrant> bigjools: Yes.
[10:02] <wgrant> Job runner daemons.
[10:02] <nigelb> bigjools: YES!
[10:02] <wgrant> Consuming immediately from rabbit.
[10:02] <wgrant> It will be glorious.
[10:02] <wgrant> GLORIOUS
[10:02] <bigjools> yes and yes
[10:02] <ajmitch> rabbit allows for scheduling at a specific time, or will you just run tasks as available?
[10:02] <bigjools> which is something I was doing 18 years ago in a former job, but meh
[10:02] <stub> chaos! glorious CHAOS!
[10:03] <nigelb> ajmitch: as available.
[10:03] <bigjools> it's to reduce latency and load spiking
[10:03] <ajmitch> so karma updates would happen during the day rather than all at once? :)
[10:03] <bigjools> we need a way to specify cumulative updates though
[10:04] <bigjools> ajmitch: we have many, many cron jobs. one at a time :)
[10:04] <ajmitch> everyone knows that LP is all about the karma :)
[10:05] <nigelb> kim0 tweeted this the other day "Ask a sysadmin about something and he'll tell you there's a cron for that"
[10:06] <nigelb> I can totally believe Launchpad having many, many, many crons.
[10:07] <lifeless> > 200
[10:07] <nigelb> Achivement Unlocked - I just rocketfuel-branch'd a branch starting with destroy.
[10:07] <nigelb> ajmitch: Personally, I think we should have badges as well.
[10:07] <ajmitch> hah
[10:07] <nigelb> Like what stackoverflow does.
[10:08] <ajmitch> nigelb: certainly, I've collected a few on askubuntu
[10:08] <bigjools> I think we need a penis icon that gets longer and longer
[10:08] <nigelb> heh
[10:08] <ajmitch> bigjools: where would you fit it in the UI?
[10:09] <lifeless> ajmitch: tell users they need multiple monitors.
[10:09] <ajmitch> heh
[10:09] <bigjools> you don't need to, you just lie about its size
[10:10] <nigelb> I should suggest the badges idea at some point. But there stuff I'd like to see before that.
[10:10] <nigelb> Like instant gratification for buying commercial subscriptions
[10:10] <lifeless> yes
[10:10] <ajmitch> then you have people doing things for the sake of badges, like commenting on 50 bugs
[10:10] <lifeless> fwiw I think gamification has to be done ----very----- carefully
[10:10] <lifeless> pathological incentives are terrible.
[10:11] <lifeless> we already have badges for team memberships after all
[10:11] <lifeless> and have seen folk making farms of teams with badges
[10:11] <nigelb> ajmitch: Right. It needs to be done carefully. There already are people joining teams for bade collection..
[10:11] <nigelb> err, what lifeless said.
[10:13] <nigelb> There are also people creating blueprints and answering questionst for karma :/
[10:14]  * ajmitch has got no further with being able to log in to launchpad.dev, sadly :)
[10:22] <bigjools> get any reviews yet rvba?
[10:22] <rvba> bigjools: nothing yet.
[10:46] <nigelb> Hrm, is there a reason why on my ~ page only bugs assigned to me *and* In Progress are shows?
[10:46] <nigelb> *shown
[10:47] <nigelb> Ideally, I'd like to see everything that's valid and not closed.
[10:59] <wgrant> It's the "Working on" section.
[11:00] <wgrant> /~/+assignedbugs shows everything assigned.
[11:00] <nigelb> aha
[11:12] <bigjools> wgrant: ok finished reading that page
[11:12] <bigjools> finally
[11:13] <bigjools> wgrant: interesting analysis, although I am not sure why you marked two of the rows as "bad" in the last query output.
[11:15] <nigelb> bigjools: You'll love this - "BCCI refuse sponsorship offer from Branson-We can't have VIRGIN written on our shirts, when we're getting screwed in every match in England"
[11:16] <bigjools> :D
[11:19] <wgrant> bigjools: Those are the two that expired the 53 binaries.
[11:19] <bigjools> how do you know?
[11:20] <wgrant> Just above that I have a list of the LFAs with their expiry dates.
[11:20] <wgrant> Let me open that page.
[11:20] <bigjools> ok
[11:20] <bigjools> there are some leaps of logic that are hard to follow
[11:21] <bigjools> let's go through this
[11:21] <bigjools> might be easier on a call
[11:21] <bigjools> s/might/will be/
[11:22]  * wgrant finds headset.
[11:22] <bigjools> skype is better, mumble gets on my nerves
[11:23] <bigjools> or voip for purists
[11:23] <wgrant> I only have mumble set up... let's see if Skype likes oneiric.
[11:24] <stub> nigelb: So what did you need to know about https://bugs.launchpad.net/launchpad/+bug/88545 ?
[11:24] <_mup_> Bug #88545: Abolish the "statusexplanation" database field <lp-bugs> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/88545 >
[11:25] <stub> nigelb: It needs to be done in two steps. First is purging that column from our code. Once that is landed and deployed everywhere, we then land a db patch to drop the actual column.
[11:26] <nigelb> stub: StevenK asked me to check with you about the expensiveness of the db patch
[11:26] <stub> Dropping the column is not expensive.
[11:27] <nigelb> Excellent, I'll go ahead with a destroy branch
[11:27] <stub> PG doesn't rewrite the table or anything - the column is just flagged 'removed' and new rows won't store the data but old rows keep the crap until we recompact the table.
[11:28] <nigelb> that's the bit that'll be expensive?
[11:30] <stub> its the bit we don't bother with, as it will happen eventually with PG upgrades and similar.
[11:30] <nigelb> cool, ok :)
[11:30] <nigelb> Oh, and how does one write a db patch?
[11:30] <stub> We do it if we really need the space or if things are performing badly because of the waste
[11:31] <wgrant> bigjools: Skype seems to work.
[11:31] <wgrant> bigjools: Ready when you are.
[11:31] <bigjools> ok
[11:31] <bigjools> opne mo
[11:31] <bigjools> one
[11:31] <bigjools> just looking at jtv's patch now!!!
[11:31] <stub> nigelb: There are guides on the wiki. You branch from lp:launchpad/db-devel and add a .sql script to database/schema similar to the others in there. The file name requires a number which someone will need to allocate for you.
[11:32] <nigelb> stub: okay, I'll worry about it when I land the code changes :)
[11:36] <stub> nigelb: Cool. I don't think we need to worry about waiting for deployment between landing the code changes on launchpad/devel and the db changes on launchpad/db-devel. We do need to wait for those code changes to have been merged into db-devel though.
[11:41] <nigelb> ok!
[11:42] <StevenK> nigelb: IE, it will hit db-devel pretty much after it hits stable
[11:51] <nigelb> StevenK: yeah, I understand now :)
[11:52]  * nigelb is waiting for EOD to start working on this.
[11:55] <rvba> stub: Hi, when you get a chance, could you please have a look at this mp: https://code.launchpad.net/~rvb/launchpad/sync-bug-827608-spph-creator/+merge/74571
[11:55] <rvba> It's only huge because of the changes in database/sampledata
[11:56] <rvba> stub: I'm wondering if CONCURRENTLY should be used for the index creation.
[12:13] <jtv> Still no reviewers in the house?  Need one for https://code.launchpad.net/~jtv/launchpad/bug-844577/+merge/74568
[12:13] <jtv> rvba: I won't be sticking around much longer though.
[12:13] <jtv> jcsackett: are you reviewing today?
[12:14] <bac> jtv: i can look at it in an hour or so if jcsackett isn't around today
[12:14] <jtv> bac: that'd be great, thanks.  I sort of promised this stuff would finally be done this week, and I'd be ecstatic to be able to land it tomorrow.
[12:15] <rvba> jtv: I'll let jcsackett handle the reviews when you're gone.
[12:15] <bac> jtv: well let's go for ecstasy then
[12:15] <jtv> rvba: OK, better take me off the topic now though.  :)
[12:15] <jtv> bac: an oft-heard phrase in Amsterdam, actually.
[12:15] <jtv> Sort of like "let's go for a beer."
[12:15] <bac> rvba: great that you're reviewing now!
[12:17] <rvba> bac: Well, I must say this first reviewing session has been quiet ;)
[12:18] <bac> rvba: that happens.  much preferred to the days when we always had a huge backlog
[12:19] <rvba> jtv: I'll find someone to mentor my review if anything comes up before jcsackett takes over.
[12:19] <jtv> OK
[12:19] <rvba> jtv: Thanks a lot for your support.
[12:20] <jtv> rvba: well you haven't needed any!
[12:20] <rvba> jtv: Indeed but I appreciate the gesture anyway ;)
[12:21] <jtv> You and your Gallic chivalry.  :)
[12:21] <rvba> hehe
[12:25] <bigjools> \o\
[12:26] <bigjools> we need a smiley for a Gallic shrug
[12:26] <rvba> Ok, that was a Gallic shug then ;)
[12:27] <bigjools> not intentionally :)
[12:31] <jtv> I suppose a Gallic shrug would be something like " M "
[12:31] <bigjools> that just looks like someone doing air quotes
[12:31] <jtv> I mean M
[12:31] <jtv> but I quoted it.
[12:31] <bigjools> ^O^
[12:32] <jtv> The shruggie was meant to be the bit between the quotes.
[12:37] <jtv> The ^O^ does have a certain gastonic quality about it.
[12:41] <bigjools> jtv: it could also be someone turning into a bat
[12:42] <jtv> hmm yes, happens all the time so people would get confused
[12:54]  * bac begins jtv's review
[12:54] <jtv> thanks bac!
[12:54]  * bac sees mention of Gina and has instant regret
[12:55] <nigelb> haha
[12:55] <rvba> bac: This review was a trap!
[12:55] <nigelb> Nicely played ;)
[12:59] <stub> rvba: No CONCURRENTLY in DB patches ('make schema' will fail in any case). We add that in manually if we apply the patch live.
[12:59] <rvba> stub: Okay.
[13:00] <jml> I'm starting to work on something that's going to need a db patch.
[13:00] <jml> Should I still start from db-stable?
[13:01] <stub> rvba: Its not 2010 either, so the copyright in the patch is incorrect.
[13:01] <rvba> stub: Arg ... sorry about that.
[13:02] <rvba> Fixed.
[13:02] <stub> rvba: Do you want me to allocate a patch number or are you happy doing that yourself?
[13:03] <rvba> stub: I'm happy to do it ... could you just point me out the right direction?
[13:03] <stub> lp:~launchpad/+junk/dbpatches
[13:04] <rvba> Okay.
[13:06] <wgrant> jml: db-stable is probably. But unless something goes really wrong, we'll be merging db-stable into devel for the first time in 2 months tomorrow.
[13:06] <wgrant> db-stable is probably best, that is.
[13:07] <jml> wgrant: thanks. are there any differences to what I should do now to what I would have done two years ago?
[13:07] <wgrant> jml: DB patches and code must be in separate branches.
[13:07] <jml> I looked on the wiki, but couldn't find anything.
[13:07] <bac> jtv: r=bac
[13:07] <wgrant> jml: We must be able to deploy the DB patch without the code.
[13:07] <jml> wgrant: and the code without the db patch?
[13:07] <jtv> Thanks again bac
[13:07] <wgrant> jml: That's not really defined yet.
[13:08] <wgrant> jml: But at the moment, no, the code usually depends on the DB patch.
[13:08] <wgrant> So you land DB patch to db-devel, then code to db-devel separately.
[13:08] <wgrant> We apply the patches, then merge db-stable to devel, and deploy the code.
[13:34] <wgrant> jml: It's maintained by buildout, so it should start out empty.
[13:34] <jml> hmm.
[13:34] <wgrant> mkdir ~/launchpad/lp-sourcedeps/yui and symlink it into devel, I guess.
[13:35] <wgrant> I wonder if the upgrade code was dropped at some point.
[13:35] <jml> OK. I think it's actually created by buildout. So my *real* question is, why does link-external-sourcecode link it
[13:35] <wgrant> But it's only like 2 months old...
[13:35] <nigelb> AH, rf-get is what got it for me.
[13:35] <wgrant> jml: Ah, so it probably only ends up in lp-sourcedeps in new installations.
[13:35] <wgrant> jml: Same reason we share eggs/: caching for speed.
[13:35] <wgrant> Although yui isn't too expensive yet.
[13:35] <jml> Oh, I see. And it can't live in eggs/ because it's not Python.
[13:35] <rvba> jcsackett: Hi, I think I'll leave you the floor since I'm mentor less atm ;)
[13:35] <jcsackett> rvba: sounds fine. :-)
[13:36] <nigelb> yay, EOD. Now to work on the destroy branch.
[13:36] <jcsackett> rvba: how did your first day of review go?
[13:36] <rvba> jcsackett: 0 reviews asked, 0 reviews done ;)
[13:36]  * jcsackett laughs
[13:36] <jcsackett> yeah, that happens from time to time.
[13:37] <rvba> The only branches up for review are mine.
[13:37] <jcsackett> rvba: soon, you will have a day where 17 reviews hit the queue at the same time. frequently as you're heading to lunch. :-)
[13:37] <rvba> hehe
[13:37] <nigelb> Like wating for a bus? ;)
[13:41] <rvba> jcsackett: one of my branches seems huge but really this is only because of the mecanical modifications to database/sampledata
[13:42] <jcsackett> rvba: looking at it now. thought it was already reviewed but i see that was just db approval.
[13:42] <rvba> True.
[13:42] <jcsackett> the other one looks fine, assuming of course its prereq is alright. :-)
[13:43] <rvba> The big one is the prereq.
[13:43] <wgrant> jml: is it behaving now?
[13:43] <jml> wgrant: yep
[13:43] <wgrant> Great.
[13:43] <gary_poster> henninge, none afaik (sorry, was doing car stuff)
[13:43] <jml> unittest2?
[13:43] <jml> really?
[13:44] <wgrant> jml: I think that's for Chameleon.
[13:45] <wgrant> Chameleon seems to be a bit special in far too many ways.
[13:45] <jml> OK.
[13:45] <wgrant> Don't worry, we're not using it :)
[13:45] <wgrant> it == unittest2
[13:46] <jml> good good :)
[13:46] <nigelb> what's Chameleon?
[13:46] <wgrant> A templating engine.
[13:46] <wgrant> Implements TAL and some other stuff, I believe.
[13:46] <wgrant> We use it on a page or two.
[13:46] <gary_poster> jml, why it would be bad if we were?  It's stdlib 2.7, yeah?  Don't know much beyond that
[13:47] <jml> gary_poster: prejudice.
[13:47] <gary_poster> jml :-P
[13:47] <nigelb> wgrant: A page or two? Isn't tal everywhere?
[13:47] <nigelb> Or was that irony I failed to catch :P
[13:47] <gary_poster> nigelb, Chameleon is an optimized engine
[13:47] <gary_poster> we use a legacy engine everywhere
[13:47] <wgrant> We use another TAL interpreter for the rest of the site.
[13:47] <wgrant> Right.
[13:47] <gary_poster> there's a LEP to switch the rest
[13:47] <nigelb> AHHHH.
[13:48] <gary_poster> It is supposed to save 10-20% processing across the board, IIRC.  It's been awhile since I did the research and tests
[13:51] <bigjools> what we lose in render time, we gain in cronspam!
[13:52] <nigelb> I was just about to ask why we didn't do that.
[13:52] <gary_poster> :-P
[13:53] <gary_poster> bigjools, there's an RT for that.
[13:54] <bigjools> We're just like an alternative Apple app store
[13:54] <gary_poster> :-)
[13:54] <jcsackett> rvba: code in the big branch looks fine. one curiousity though. why remove the comments on columns like potemplate? i don't see anything wrong with doing so, just curious if that was cleanup or somehow within the scope of your changes.
[13:57] <gary_poster> nigelb, because it is non-trivial work.  See Gotchas and schedule at bottom of https://dev.launchpad.net/LEP/Chameleon That analysis itself has been overtaken by events since it was written.
[13:57] <gary_poster> For instance, on the bright side, maybe some of the Gotchas are no longer a problem because the newer version of Chameleon has greater compatibility.  On the not-so-bright side, we would need to rewrite the memcache tal plugin again, or decide conclusively to rip it out as failed; and do a reanalysis of What Breaks Now.
[13:58] <nigelb> fun.
[13:59] <gary_poster> yeah
[14:01] <henninge> gary_poster: ok, I'll mark the bug as qa-ok then. (Sorry, was otp)
[14:01] <rvba> jcsackett: no, that's not within the scope of my branch, let me have a look at that.
[14:02] <henninge> or rather qa-untestable?
[14:02] <jcsackett> rvba: like i said, it's not a big deal. the comments all basically are "this is the $var" where $var is the name of the column *anyway*.
[14:02] <gary_poster> henninge, np, I am about to go on phone, but I was going to try and put a branch in junk for the heck of it as a smoketest.  If you can do that it would be great; if not I'll do it after I get off call
[14:02] <henninge> gary_poster: yeah, I'll do that.
[14:02] <jcsackett> so removing them has not materially changed the documentation. :-P
[14:03] <gary_poster> thank you very mucj henninge
[14:03] <henninge> np ;)
[14:10] <jml> Can someone please give me a patch number?
[14:11] <jml> https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#Patch%20ids says I need one before continuing.
[14:12] <rvba> jml: I'm just modifing the patch number file.  If you give me a comment I'll do it for you.
[14:12] <jml> rvba: what sort of comment?
[14:12] <rvba> jml: like what the patch does.
[14:13] <jml> rvba: "Add tables for a package symbol database"
[14:13] <rvba> jml: Okay sir, here is your patch number: 2208-83-1 ;)
[14:13] <jml> rvba: thank you.
[14:13] <rvba> np
[14:16] <rvba> jcsackett: I've fixed the comment removal. That was due to an unfortunate manipulation.
[14:16] <jcsackett> rvba: ah, cool stuff.
[14:16] <rvba> jcsackett: BTW I also fixed the patch number, it was 2208-82-0 and I changed it to 2208-82-1
[14:16] <jcsackett> rvba: ok.
[14:17] <jcsackett> rvba: looks good, branch is r=me.
[14:17] <rvba> (the reason I did that is explained in the last paragraph of http://bazaar.launchpad.net/~launchpad/+junk/dbpatches/view/head:/allocated.txt)
[14:17] <rvba> jcsackett: cool, thanks.
[14:19] <abentley> gary_poster: Do you know what buildout does with binaries?  I've added Celery to buildout, but I can't find celeryd anywhere.
[14:20] <nigelb> To delete a db field, I need to remove all instances that the field is being used, right?
[14:20] <gary_poster> abentley, on call, but look in egg in EGG-INFO.
[14:26] <gary_poster> abentley, you can also put a binary in bin.  There are a couple of ways, but most standard is to use entry_points in setup.py
[14:27] <gary_poster> you can see examples there now
[14:27] <abentley> gary_poster: It seems to have entry points already: http://pastebin.ubuntu.com/685317/
[14:28] <henninge> Should code hosting on qastaging be expected to behave differently from production?
[14:28] <gary_poster> abentley, yes those are if you install it in a Python.  Use what I told you for those entrypoints
[14:28] <gary_poster> on call again
[14:29] <abentley> henninge: yes.
[14:29] <abentley> henninge: codehosting on qastaging has only a small subset of branches physically present.
[14:29] <henninge> abentley: i saw this when pushing http://paste.ubuntu.com/685307/
[14:29] <henninge> ah, I see
[14:30] <henninge> abentley: but what about new branches
[14:30] <henninge> I had to push twice.
[14:30] <henninge> also, the branchscanner is either very slow or not running.
[14:30] <abentley> henninge: I believe it's very slow.
[14:31] <abentley> henninge: I wouldn't expect the first push to error like that.
[14:31] <wgrant> It runs on staging, but I don't believe it runs regularly on qastaging.
[14:31] <wgrant> That first error was because it's trying to stack on a branch that isn't on qastaging.
[14:31] <wgrant> The subsequent push will see that the bzrdir exists, so not try to stack again.
[14:32] <henninge> that seems to make sens
[14:32] <henninge> e
[14:32] <henninge> Pushing to +junk went fine btw.
[14:32] <abentley> henninge: I can't reproduce your issue: http://paste.ubuntu.com/685321/
[14:33] <wgrant> +junk doesn't stack.
[14:33] <wgrant> So that's unsurprising.
[14:33] <abentley> henninge: was there a previous push attempt?
[14:33] <abentley> wgrant, henninge: true.  It would be complaining about the missing development focus branch.
[14:33] <wgrant> Exactly.
[14:34] <henninge> abentley: pushing to +junk worked fine for me, too.
[14:34] <henninge> abentley: my bzr complains about lp://staging/ urls. What might be missing/old?
[14:35] <abentley> henninge: bzrtools development focus is always present on (qa)staging.  Can you push as a branch of that instead?
[14:35] <abentley> henninge: I don't know.  What's the complaint?
[14:35] <henninge> "not a valid url"
[14:35] <henninge> I will try bzrtools
[14:36] <abentley> henninge: And it's complaining about qastaging, not staging?
[14:36] <abentley> henninge: I mean, I can understand if it doesn't grok lp://qastaging, because that's newish.
[14:36] <abentley> henninge: But lp://staging has been supported for years.
[14:37] <henninge> yes, that works.
[14:39] <henninge> abentley: and bzrtools works flawlessly, too. ;)
[14:40] <henninge> thanks abentley, wgrant
[14:40] <abentley> henninge: qastaging support was introduced to trunk in January, and should be in bzr 2.4.
[14:40] <henninge> abentley: ah, I am running 2.3.4
[14:41] <henninge> that's probably stock natty.
[14:44] <henninge> abentley: there are two ppas in my config (deactivated): /bzr/ubuntu and /bzr/ppa/ubuntu
[14:44] <henninge> abentley: which one should I use?
[14:44] <henninge> or both
[14:44] <henninge> ?
[14:45] <abentley> henninge: bzr/ppa
[14:48] <henninge> abentley: thanks, now I am on 2.4, too
[14:49] <abentley> henninge: np
[14:56] <henninge> Hi bac! How far along are you with QA for bug 838957? Need any help?
[14:56] <_mup_> Bug #838957: AssertionError: Search by component requires a context with a distribution or distroseries. <oops> <qa-needstesting> <Launchpad itself:Fix Committed by bac> < https://launchpad.net/bugs/838957 >
[14:56] <bac> henninge: i'm doing it now, thanks
[14:56] <henninge> bac: awesome, thank you ;)
[14:56] <bac> should just take a sec
[14:56] <bac> henninge: it's gary you need to harass!
[14:56] <bac> :)
[14:57] <henninge> bac: I am done with that ;)
[14:57]  * bac hurries...
[14:57] <henninge> "Don't rush the miracle man or you'll get the wrong miracle."
[14:58] <bac> henninge: done!
[14:58] <henninge> wgrant: is the buildd-manager in nodowntime?
[14:58] <henninge> bac: great, thanks
[14:58] <henninge> ;-)
[15:31] <flacoste> mrevell: we should announce that we are doing fastdowntime to our users
[15:32] <flacoste> since they might encounter a 5 minutes outage weekdays at around 8:30 UTC
[15:33] <bac> n
[15:33] <mrevell> flacoste, Cheers, I'll get a blog post etc together.
[15:33] <mrevell> bac, Hey
[15:33] <mrevell> bac, got a question for you
[15:33] <bac> hi mrevell
[15:34] <bigjools> cjwatson: how would you feel about automatically cleaning out the archive and librarian of all binaries as soon as a series is marked obsolete?
[15:34] <flacoste> mrevell: thanks! can you take care of sending the news to the stakeholders list also?
[15:34] <mrevell> flacoste, Sure!
[15:34] <flacoste> thanks
[15:37] <stub> flacoste, mrevell: I put an announcement via launchpadstatus already
[15:37] <stub> oh... just for tomorrow.
[15:37] <mrevell> Thanks stub.
[15:38] <flacoste> mrevell: it's probably important to point out that until we fix bug 844631, this will manifest itself through a bunch of OOPSes during the outage
[15:38] <_mup_> Bug #844631: Launchpad should return 503 error pages when database is unavailable <fastdowntime-later> <Launchpad itself:Triaged> < https://launchpad.net/bugs/844631 >
[15:41] <mrevell> Good point, thanks.
[15:50] <cjwatson> bigjools: it needs a grace period so that we can make sure that old-releases has something current
[15:51] <bigjools> ok
[15:51] <cjwatson> (IMO)
[15:51] <bigjools> cjwatson: is that not something you'd check before obsoleting it?
[15:51] <cjwatson> it doesn't get moved to old-releases until it's obsolete
[15:51] <bigjools> ah, faire enough.
[15:51] <cjwatson> AFAIK anyway
[15:52] <bigjools> I'm just trying to work out how to phrase a bug which captures the requirements
[15:52] <bigjools> I want to automate as much as possible - sounds like we need an extra Big Red Button
[15:53] <bigjools> cjwatson: are old sources captured on old-releases? And do you still need all the old versions?
[15:54] <cjwatson> (a) yes (b) which old versions?
[15:55] <bigjools> the superseded ones
[15:56] <bigjools> ie can we make this like binaries
[16:07] <stub> bigjools: I sometimes wonder if the Librarian should have an 'external' field which we can use to point to stuff no longer stored in the Librarian.
[16:07] <bigjools> stub: yes, we desperately need offline storage.  It's a bit nuts keeping *everything* in there.
[16:08] <elmo> blink
[16:08] <elmo> how is that not just "make it someone else's problem"?
[16:08] <elmo> if you want it online but still available, someone has to store it and make it available
[16:09] <bigjools> If you want to keep adding disk space in the librarian then I have no problem filling it up
[16:10] <stub> It very much is making it someone elses problem. I'm just wondering if it is appropriate sometimes (eg. of we are going to store archives for ever anyway on disk in an accessible format, no real point duplicating that storage in the Libraraian).
[16:13] <gary_poster> sinzui, in a fresh oneiric server, when I try to import html5browser I get a "RuntimeError: Gtk couldn't be initialized" error in gi/overrides/Gtk.py.  I can provide a traceback if that helps.  I verified that various seemingly obvious gtk packages were installed, and they were.  Is there something else relatively obvious I can try?
[16:14] <sinzui> gary_poster, thank you for reminding me. wgrant reported this as well. I think there is an undocumented dep
[16:14]  * sinzui investigates
[16:15] <gary_poster> sinzui, oh ok.  thank you
[16:17] <sinzui> gary_poster, can you paste the traceback?
[16:19] <gary_poster> sinzui http://pastebin.ubuntu.com/685391/
[16:20] <sinzui> gary_poster, fab, we did the same thing and it works for me. Maybe I can publish the correct libs in a few minutes
[16:20] <gary_poster> ok thanks sinzui
[16:27] <sinzui> gary_poster, I think the dep that marries python to gir is missing. Do you have python-gobject 2.90.3 installed
[16:28]  * gary_poster looks
[16:29] <gary_poster> sinzui, -gobject-2 @  2.28.6-6svn1
[16:29] <gary_poster> sinzui, oh and -gobject 2.90.3-1svn1
[16:29] <gary_poster> both installed
[16:30] <sinzui> gary_poster, that would be the problem  -gobject-2 is for obsolete libs
[16:30] <sinzui> of dear. -gobject 2.90.3-1svn1 is the one I thought was missing
[16:30] <gary_poster> sinzui, so they would conflict?  Should I try to install -gobject-2?
[16:30] <gary_poster> I mean uninstall
[16:30] <gary_poster> sorry
[16:31] <sinzui> gary_poster, they do not, and I happen to have it installed. give it a try
[16:31] <gary_poster> sinzui, "python-gobject depends on python-gobject-2 "
[16:32] <gary_poster> (and I aborted the attempt to uninstall)
[16:32] <sinzui> ah. python-webkit is a gtk2 app so it does want that lib
[16:41] <sinzui> gary_poster, can you try both of these command, are they the same TB: http://pastebin.ubuntu.com/685415/
[16:41]  * gary_poster tries
[16:42] <gary_poster> sinzui, yes, same TB
[16:42] <gary_poster> (for both)
[16:43] <sinzui> thank you that helps. This is a python-gi-gtk lib issue. Mine works by accident because I hack with that combination for other projects
[16:43] <gary_poster> ah ok
[16:48] <mtaylor> morning sinzui ... I got a weird one for you
[16:49] <mtaylor> one of our devs (~annegentle) has launchpad openid returning a different localid than annegentle. apparently this happened with adamg a little while ago and the working hypothesis is that it is related to having had an account get renamed
[16:50] <mtaylor> sinzui: any idea who the right person to ping about this would be?
[16:51] <sinzui> mtaylor, This is often caused by a disconnect between the person's login.ubuntu.com emails and launchpad.net emails
[16:51] <mtaylor> sinzui: is that something that can be sorted out by the person themselves?
[16:52] <sinzui> This was caused several times in the past by profile merges, but I think that is fixed given how rare it happens. I think this commonly happens when a user add/removed emails from wither site without knowing they are working with two sites
[16:53] <sinzui> mtaylor, I honestly do not know. I think the person should testing logging in to login.ubuntu.com to verify the registered emails, then do that with Lp and add the missing addresses to Lp
[16:55] <sinzui> mtaylor, gary_poster had some experience with this in the past. I believe the a DBA was employed on several occasions to fix the ids in either of the sites
[16:55] <mtaylor> sinzui: gotcha
[16:55] <gary_poster> hello
[16:55] <mtaylor> hey gary_poster !
[16:56] <gary_poster> :-)
[16:56] <jeblair> i've asked annegentle to verify the email addrs are in sync
[16:57] <gary_poster> So, lemme see if I can find the bug.  If it's the same problem, the proper fix is for ISD to make some changes that have been planned for a long time, but there's a recipe for fixing it on the admin side.
[16:57] <jeblair> if it helps:
[16:57] <gary_poster> So first let's verify that we're talking about the same thing.  1 sec, looking
[16:57] <jeblair> https://launchpad.net/~annegentle says the local_id is https://login.launchpad.net/+id/6sDWhGL
[16:57] <jeblair> but when she logs in, we get passed https://login.launchpad.net/+id/xQHRTxt
[16:58] <jeblair> and she did say that she has had some kind of account rename (i don't know if it was executed as a merge)
[16:59] <gary_poster> OK, this is the root bug... https://bugs.launchpad.net/launchpad/+bug/644824
[16:59] <_mup_> Bug #644824: User created a second Launchpad account; now gets mixed success/denied to various services <canonical-losa-lp> <defect> <lp-foundations> <Canonical SSO provider:Confirmed> <Launchpad itself:Fix Released by stub> < https://launchpad.net/bugs/644824 >
[17:00]  * gary_poster is scanning to try and find remediation...
[17:03] <gary_poster> mtaylor, comment #31 says that ISD can delete the bad openid account.  contacting them might be your best bet.  https://answers.launchpad.net/canonical-identity-provider/+question/150135
[17:04] <gary_poster> Alternatively we can ask losas to make a deletion on the LP side, per comment 12 of that bug.
[17:04] <mtaylor> gary_poster: so is the best way to do that to file a question against canonical-identity-provider?
[17:06] <gary_poster> mtaylor, that would be the better long term soluton, assuming anne does not want to maintain two Canonical openids.  I will also ask the losas to delete the tokens on the LP side, which should alleviate the problem for now (she will have to log in again, using the openid she actually wants to maintain)
[17:07] <gary_poster> ah, right, there's a process for this now...
[17:11] <sinzui> gary_poster, do your have libgirepository-1.0-1? I wonder if the -dev version also need to be installed, if so python-gobject-2-dev may also need installation
[17:12] <gary_poster> sinzui, I have it installed, but not the -dev
[17:12] <gary_poster> should I try it?
[17:13] <sinzui> gary_poster, I think I could be smarter about this investigation. paste or email the results of this so that I know exactly what is different about our packages:
[17:13] <sinzui> dpkg --get-selections > installed-software
[17:14] <bac> mrevell: still around?
[17:18] <mtaylor> gary_poster: ok. I'm confused now ... which thing should I be doing now. filing the question?
[17:18] <gary_poster> mtaylor, I'll do it for you, and ping you with it.
[17:18] <mtaylor> gary_poster: awesome. you are amazing
[17:24] <gary_poster> sinzui, sorry it took a sec, paste isn't set up yet and had some kind of problem
[17:24] <gary_poster> but sent
[17:24] <nigelb> wgrant: you around?
[17:27] <nigelb> wgrant: Nevermind :)
[17:34] <sinzui> gary_poster, can you install gir1.2-gtk-2.0
[17:34] <sinzui> oh, maybe I am the one without it
[17:35] <sinzui> okay I have it and I am sure webkit is a gtk2 app
[17:35] <gary_poster> sinzui, ok trying
[17:37] <gary_poster> sinzui "Setting up gir1.2-gtk-2.0 (2.24.5-0ubuntu7)" but same traceback when I try to import html5browser
[17:37] <sinzui> I will continue looking a the diff
[17:38] <sinzui> gary_poster, gir1.2-webkit-1.0
[17:38] <gary_poster> k
[17:38]  * sinzui doubts that is correct, but if it is, he will be enlighten
[17:40] <gary_poster> sinzui, same problem (and that had three dependencies)
[17:44] <sinzui> okay :( I have python-gtk2-dev  python-gobject-dev python-gobject-2-dev too
[17:44] <sinzui> They have binaries in them to
[17:45] <gary_poster> sinzui, k trying
[17:46] <gary_poster> whoo!  That'll bring in the neighbors...
[17:46] <sinzui> yuck
[17:46] <gary_poster> 59 dependencies
[17:46] <sinzui> I see only two other cases like in on the net and they were solved by installing pygobject, which is python-gobject :(
[17:48] <gary_poster> mtaylor, losas have sql request on LP side, and I filed https://answers.launchpad.net/canonical-identity-provider/+question/170575 for you on CIP side.
[17:48] <gary_poster> I will ping when sql request has been run
[17:49] <mtaylor> gary_poster: thanks man!
[17:49] <gary_poster> sinzui, !! still same error.  you want me to be paranoid and do something crazy like restart or something?  That seems crazy, but...
[17:49] <gary_poster> welcome mtaylor
[17:50] <sinzui> gary_poster, no restart. removed those dev packages.
[17:50] <gary_poster> ok
[17:50] <sinzui> I have started a upgrade to oneiric on another machine and I will look at the diff some more
[17:52] <gary_poster> sinzui, should I also remove gir1.2-gtk-2.0 and gir1.2-webkit-1.0
[17:52] <gary_poster> or leave 'em around till later?
[17:52] <gary_poster> sinzui, /me going to take lunch in a sec
[17:52] <gary_poster> oh...
[17:53]  * gary_poster has call soon :-P
[17:53] <sinzui> gary_poster, take your time. I will continue to work on this
[17:53] <gary_poster> ok thanks sinzui
[18:01] <sinzui> gary_poster, Gtk is a GUI lib, as webkit is a gui app. you do not have an x server up
[18:09] <bac> sinzui: is it possible to get the openid identifier for a user now?  it used to be in the +rdf but isn't now
[18:09] <gary_poster> sinzui, duh!  sorry, I should have thought of that.  xvfb it is
[18:09] <sinzui> bac it is not, but it is a trivial bug fix to remove the constraint in the template
[18:09] <sinzui> the bug is already reported
[18:10] <bac> sinzui: ok.  i needs it now, though.  :(
[18:10] <sinzui> gary_poster, Sorry for being so slow. I always test html5browser with
[18:10] <sinzui> Xvfb :23 -ac -screen 0 1024x768x24 &
[18:10] <sinzui> env -i DISPLAY=:23  ./bin/py
[18:10] <sinzui> I should have read my own notes before asking you to tell me what is installed
[18:11] <gary_poster> :-) thanks again
[18:33] <nigelb> rockstar: Hi, around?
[18:33] <rockstar> nigelb, I am.
[18:34] <nigelb> rockstar: lifeless suggested I talk to you about how U1 web deals with javascript oops for potentially duplicating it in LP :)
[18:34] <rockstar> nigelb, short answer: we don't.
[18:34] <rockstar> :)
[18:34] <nigelb> Oh.
[18:35] <rockstar> We've disabled jsoops for the time being, because it got in the way more than it helped.
[18:35] <rockstar> nigelb, however, we're going to refactor it as soon as I'm done with my current project, which should release soon.
[18:35] <nigelb> Ouch, okay
[18:36] <nigelb> rockstar: Any pointers on what's the "right way" to do it?
[18:37] <rockstar> nigelb, so, the very basics of it are this:
[18:38] <rockstar> window.onerrer = function() { new Image().src = '/jsoops/endpoint' };
[18:38] <gary_poster> mtaylor, please ask anne to try logging in again
[18:38] <rockstar> nigelb, of course, the onerror function has message, url, and line arguments.
[18:39] <nigelb> okay
[18:39] <nigelb> But Image?
[18:40] <mtaylor> gary_poster: will do
[18:42] <nigelb> rockstar: I'm curious, why the Image()? Does the jsoops load and image to show the user?
[18:43] <rockstar> nigelb, it's just a neater way to make a GET request than XMLHttpRequest
[18:43] <rockstar> You never add the image to the DOM.
[18:44] <rockstar> Also, you don't have to worry about the domain there either.
[18:44] <nigelb> Oooh. Interesting!
[18:45] <rockstar> nigelb, so, the endpoint itself will has ?message=...&url=...&line=... so you just make sure the endpoint knows what to do.
[18:45] <nigelb> Oh, so these gets logged by the endpoint for future usage?
[18:45] <nigelb> usage/triager/debugging/fixing
[18:45] <rockstar> nigelb, Be advised, however, that YUI will step all over that once it gets loaded, so you'll have to do something a bit more YUI-ish after that.
[18:45] <rockstar> nigelb, exactly.
[18:46] <rockstar> nigelb, so we do Y.one(Y.config.win).on('error', function(e) { new Image()... }); once YUI gets loaded.
[18:47]  * rockstar feels another blogpost coming on.
[18:47] <nigelb> rockstar: Nice. But we'd be doing a GET to write data in this case right?
[18:47] <nigelb> rockstar: WRITE IT! :)
[18:48] <rockstar> nigelb, not necessarily.  You could parse logs after the fact, since you usually don't want to write on GET (and Launchpad specifically forbids it).
[18:48] <rockstar> You don't even have to have an actual endpoint.  You could just parse Apache's logs.
[18:49] <nigelb> Oh, right.
[18:49] <nigelb> Yeah.
[18:53] <rockstar> nigelb, the Ubuntu One web team is a bit more fast and lose when it comes to errors though.  It's often enough to see a graph of errors, rather than the actual errors.
[18:54] <rockstar> (at least in the client)
[18:54] <nigelb> rockstar: Oh, then you debug based on their numbers? (rising, decreasing)
[18:55] <rockstar> nigelb, yeah, and usually it's pretty simple to find, especially if you get the url right.
[18:55] <rockstar> Most of the time it's an unsupported browser, and the error was thrown right before the user got the "non-javascript" experience.
[18:57] <nigelb> rockstar: ooh, right. But this at least seems fairly trivial to do.
[18:57] <nigelb> may be its my ignorance though :)
[18:58] <rockstar> nigelb, yeah, it's not difficult, no.
[18:58] <rockstar> nigelb, but you get lots of edge cases (also referred to as "what users do") that make things less trivial.
[18:58] <nigelb> I'll run it by lifeless or stub and ask for more comments before I start writing anything :)
[18:58] <rockstar> For instance, you don't want the error to break the rest of the page.
[18:59] <bac> sinzui: is this the bug you referenced? https://bugs.launchpad.net/launchpad/+bug/501731
[18:59] <_mup_> Bug #501731: XRDS for launchpad users missing local id <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/501731 >
[19:00] <rockstar> nigelb, also, remember that in a few weeks, U1 is re-addressing this, so we might want to knowledge share a bit.
[19:00] <lifeless> nigelb: we'd generate a custom oops on GET, its not modifying the resource in the usual rfc2616 sense, so would be OK.
[19:01] <nigelb> lifeless: So, what rockstar proposed sounds good?
[19:01] <lifeless> yes, thats why I pointed you at him :)
[19:02] <sinzui> bac no. I misunderstood you question. I thought you wanted the openid url which is shown only to yourself on your profile page
[19:02]  * rockstar writes down in his diary "Dear diary, today lifeless approved of something I was doing. It made me feel all warm inside!"
[19:02] <sinzui> bac: there is no bug/request to leak the id
[19:02] <nigelb> rockstar: haha
[19:04] <nigelb> lifeless: so, having a stub URL with nothing, on javascript error, do a GET request to that endpoint, look at logs in apache?
[19:05] <lifeless> nigelb: s/look at logs in apache/create a custom oops/
[19:06] <nigelb> lifeless: hrm, so the stub URL should grab it and push it somewhere?
[19:06] <nigelb> custom logs?
[19:06] <nigelb> like what wsgi-oops does?
[19:06] <lifeless> it will translate between whatever format the javascript is producing and an oops report
[19:07] <lifeless> probably wanting a custom oops.Config() without the in-appserver-hooks installed, because we're not reporting a problem *in this appserver*.
[19:08] <lifeless> but don't take this bit literally: thats detail to figure out when doing it
[19:08] <nigelb> lifeless: I think I need to look at how LP does oops. I have not much clue :)
[19:09] <lifeless> lib/canonical/launchpad/webapp/errorlog.py - allow a couple of hours to read it and the supporting libraries and generally play around getting a feel for whats under the hood
[19:09] <nigelb> okay, doing that over the weekend
[19:15] <nigelb> rockstar: when you modify the jsoops for u1, I'd be intersted in details :)
[19:19] <lifeless> nigelb: Oh, one further tweak: I suggest a dedicated plain-ol-simplewsgi daemon for doing js oops collection
[19:20] <lifeless> nigelb: it has no reason to be in either the LP or u1 services; we can map the submission url to the daemon via apache
[19:22] <rockstar> lifeless, I would most certainly agree.
[19:24] <nigelb> lifeless: ah, this is part of the service oriented architecture bit?
[19:25] <lifeless> nigelb: no more than anything else
[19:25] <lifeless> nigelb: also no less so than anything else
[19:26]  * nigelb couldn't parse that :P
[19:26] <lifeless> nigelb: everything we do gets an soa assessment now
[19:26] <nigelb> AH!
[19:26] <nigelb> lifeless: so I can just write something in paste? ;)
[19:27] <lifeless> nigelb: yes, or even simpler :)
[19:27] <nigelb> Or just a wsgi app, right.
[19:27] <lifeless> nigelb: lp:~lifeless/+junk/gpgverify might have some ideas; I *think* I pushed my simpleserver version
[19:27] <nigelb> I'm going through error.py
[19:28] <lifeless> not that
[19:28] <nigelb> I'll add it to my reading list after that :)
[19:28] <lifeless> errorlog.py
[19:28] <nigelb> gah
[19:29] <lifeless> ah, I'm still using web.py there
[19:29] <lifeless> ah! its the gpgfixtures test keyserver I used simpleserver
[19:30] <lifeless> http://bazaar.launchpad.net/~canonical-launchpad-branches/python-gpgfixtures/trunk/view/head:/gpgfixtures/keyserver.py
[19:31] <nigelb> *click*
[19:31] <lifeless> thats a microservice I was about ready to get the LP test suite to use when I went on leave ;)
[19:32] <lifeless> wgrant was mumbling about finishing the migration off
[19:32] <lifeless> okies, I have to run; ciao!
[19:32] <nigelb> Laters!
[19:33] <nigelb> Thanks :)
[19:55] <jeblair> gary_poster, mtaylor: annegentle is still showing up with the old id, though her launchpad page now lists _no_ openid info
[19:56] <gary_poster> jeblair, she needs to log out and log back in.
[19:57] <jeblair> that was after a browser restart...
[19:57] <gary_poster> jeblair, IIRC, and I'm pretty sure I do, the session cookie will be retained after a browser restart.  If she didn't log out and in again, there will be no change.
[20:00] <jeblair> gary_poster: ok. i'll let her know.
[20:02] <gary_poster> jeblair, I've also subscribed her to the question I filed for her against canonical identity provider (https://answers.launchpad.net/canonical-identity-provider/+question/170575) so if there is any reply there, she should know.  You or others can subscribe to replies as well, if desired.
[20:04] <jeblair> gary_poster: thanks!
[20:04] <gary_poster> welcome
[20:19] <benji> jcsackett: do you have a minute to review lp:~benji/lazr.restful/error-on-multiple-ws.op-fields ?
[20:20] <jcsackett> benji: sure thing.
[20:21] <jcsackett> benji: i don't actually see an MP for that branch.
[20:21] <sinzui> jcsackett, I am reviewing your branch now. I am going to to run it to see it
[20:21] <benji> jcsackett: heh, you are correct; one second
[20:21] <jcsackett> sinzui: ok. sorry i forgot to post screenshots. :-)
[20:23] <salgado> can somebody with the needed rights see the contents of a private branch on bazaar.launchpad.net/...?
[20:25] <benji> jcsackett: here you go: https://code.launchpad.net/~benji/lazr.restful/error-on-multiple-ws.op-fields/+merge/74682
[20:36] <jcsackett> benji: i'm not getting a diff generated, any chance you can throw the diff to me as a paste?
[20:36] <benji> jcsackett: http://paste.ubuntu.com/685561/
[20:36] <jcsackett> thanks.
[20:38] <jcsackett> benji: looks good to me. r=me.
[20:39] <benji> thanks!
[21:17] <salgado> does launchpad the web app have access to the contents of bzr branches?
[22:07] <nigelb> Anyone awake? :)
[22:07] <nigelb> I'm removing a field completely.
[22:07] <nigelb> Is it okay to remove statusexplanation = StringCol(dbName='statusexplanation', default=None)
[22:07] <nigelb> from the model?
[22:16] <mwhudson> if nothing references it, sure
[22:17] <nigelb> I'm removing everything else that references it as well.
[22:18] <reed> hello folks
[22:18] <reed> is there a way to download the mailing list archives from launchpad? (like pipermail does)
[22:23] <nigelb> grar, postgres error. /me postpones for tomorrow.
[22:37] <reed> argh https://bugs.edge.launchpad.net/launchpad/+bug/588411
[22:37] <_mup_> Bug #588411: downloading of mailing list archives <feature> <lp-registry> <ml-archive-sucks> <Launchpad itself:Triaged> < https://launchpad.net/bugs/588411 >
[22:37] <sinzui> reed, there is not
[22:38] <reed> sinzui, very unfortunate
[22:38] <reed> I'll update the bug: that's a very important feature to collect metrics on the mailing lists
[22:38] <sinzui> reed,  you can ask a question at answers.launchpad.net/launchpad. An admin can get you a copy of the archive
[22:39] <reed> I need them on an ongoing basis, like every week or month
[22:39] <sinzui> reed, mailing lists are not a priority now. I can update the bug with detail about the scope of the effort for community members implement
[22:40] <reed> I can add a comment on the bug too if you want
[22:40] <reed> I understand it's not a priority for you at the moment though... I hope you'll reconsider :)
[22:43] <reed> sinzui, if there is a way to get the past archives as a one off, I may setup a workaround to gather new messages locally and process the stats from the local archive
[22:45] <sinzui> reed, I believe other people have done that. As I said above, and admin can get you a copy of the archive
[22:46] <reed> thanks
[22:50] <nigelb> Achivement unlocked.
[22:50] <nigelb> Removed a field successfully. Or so I think.
[22:54] <poolie> hi all
[22:54] <poolie> way to go nigelb :)
[22:54] <nigelb> Morning poolie!
[23:13] <wgrant> sinzui: Sorry, can't be at the standup this morning. I can probably talk in an hour or so if you want.
[23:14] <sinzui> okay. I will check back later
[23:16] <nigelb> wgrant: Is psycopg2.OperationalError: fe_sendauth: no password supplied related tosomething you and jtv were talking on the list?
[23:16] <nigelb> (for tests)
[23:17] <StevenK> sinzui: 35. http://paste.ubuntu.com/674281/
[23:17] <wgrant> nigelb: Yes, that same thing.
[23:17] <wgrant> nigelb: Wait, no, not jtv.
[23:17] <wgrant> nigelb: My other email to the list.
[23:17] <wgrant> Not the reply to jtv.
[23:19] <nigelb> wgrant: Okay :) Updating my setup
[23:20] <nigelb> wgrant: Wait, but I'm not on ipv6 :/
[23:21] <nigelb> StevenK: I join your ranks with a destroy- branch ;)
[23:21] <nigelb> +8/-58  not much though
[23:22] <wgrant> nigelb: You have loopback IPv6.
[23:22] <wgrant> What does your /etc/hosts look like?
[23:22] <nigelb> Ah
[23:22] <nigelb> ::1     localhost ip6-localhost ip6-loopback
[23:23] <wgrant> That is the problematic bit.
[23:23] <wgrant> Apply the fix, and all should be good.
[23:23]  * nigelb runs l-d-s again
[23:23] <wgrant> Anyway, I need to wander off properly for a while.
[23:24] <nigelb> :)
[23:24] <nigelb> thanks!
[23:24] <nigelb> (I should sleep)
[23:40] <wgrant> wgrant@carob:~/logs$ find */2011-09-07 -type f | wc -l
[23:41] <wgrant> 5226
[23:41] <wgrant> wgrant@carob:~/logs$ find */2011-09-08 -type f | wc -l
[23:41] <wgrant> 72430
[23:41] <wgrant> fastdowntime appears to have worked...
[23:43] <lifeless> thats more than expected ;)
[23:43] <lifeless> 2minutes at 900rpm => 1800 failures
[23:43] <wgrant> They were mostly appserver OOPSes.
[23:43] <wgrant> I calculated there were about 60000 extra appserver OOPSes, from the OOPS IDs at the time.
[23:43] <wgrant> And yes, it is slightly high.
[23:44] <wgrant> Er.
[23:44] <wgrant> 900rpm?
[23:46] <wgrant> Considering the appservers serve up to 14M requests a day (normally around 9-10M), 900 per minute is a little low :)
[23:47] <lifeless> EONLEAVE.
[23:47] <lifeless> we may need to revisit capacity again shortly.
[23:47] <lifeless> anyhow, 3600 <<< 60000
[23:48] <wgrant> >>> (10000000 / 86400) * 132
[23:48] <wgrant> 15180
[23:48] <wgrant> And given that the responses were immediate, API scripts would have made lots of requests.
[23:49] <lifeless> 132?
[23:49] <lifeless> seconds down ?
[23:49] <wgrant> Maybe it was 127, but yes.
[23:49] <wgrant> Roughly.
[23:49] <wgrant> 132
[23:50] <lifeless> 1736 rpm per appserver machine :)
[23:50] <lifeless> but yes, our rate is getting pretty high
[23:50] <wgrant> We had very odd spikes on the 18th and 20th
[23:51] <lifeless> are we starting to queue in haproxy again ?
[23:51] <wgrant> But given that they apply to both web and API traffic, I'm inclined to think it was something else.
[23:51] <wgrant> We've had 5 queue depth incidents in the last week.
[23:51] <wgrant> So yes.
[23:51] <lifeless> meep.
[23:51] <wgrant> They all cleared quickly, and only once did it exceed 20.
[23:51] <wgrant> But it is happening increasingly often.
[23:51] <wgrant> So yeah, we may want to expand a bit soon.
[23:51] <lifeless> we need to check the PPR and see if there has been a systematic increase (5% would be significant) in page render time
[23:52] <wgrant> Let's see how appserver load is...
[23:52] <lifeless> if not, cross check on capacity
[23:52] <lifeless> and then look at adding a core + memory to one of the appservers.
[23:52] <wgrant> Let's see..
[23:52] <lifeless> we *should* be running at N+1 at all times: hitting a queue warning -ever- is a Big Deal.
[23:53] <StevenK> lifeless: I was wondering how you were thinking of scaling -- via a 5th machine or making the 4 beefier
[23:53] <wgrant> We can scale these machines up further.
[23:53] <lifeless> StevenK: elmo wants to consolidate in the DC
[23:53] <wgrant> They're not full AFAIK.
[23:53] <lifeless> StevenK: we have 4 because 2*dc + redundancy within the DC
[23:54] <lifeless> StevenK: but thats the old (february) strategy; now we're moving DC's we're looking at something different e.g. full N+1 deploys in both DC's and one DC running hot-idle
[23:54] <lifeless> its been 2 weeks since I caught up with elmo on this, I don't know the current status.
[23:54] <wgrant> lifeless: We've had two days in the last month where average render time is 30% higher than the norm.
[23:54] <lifeless> wgrant: was the sql time likewise higher ?
[23:54] <wgrant> But apart from that it's only marginally higher.
[23:55] <lifeless> or load spikes on the appservers correlatimg with that ?
[23:55] <wgrant> The graphs don't show SQL time.
[23:55] <lifeless> wgrant: check the daily PPR report to see that.
[23:55] <lifeless> (for the day in question)
[23:55] <wgrant> Yeah.
[23:55] <wgrant> The first spike is mainly API with a bit of the rest, the second translations with a bit of the rest.
[23:56] <lifeless> bbiab
[23:58] <wgrant> The SQL increase was only 10% of the total increase.
[23:59] <wgrant> The first load spike was, interestingly, the day in between the two >13M request spikes.