[00:47] <StevenK> wgrant: http://pastebin.ubuntu.com/1189950/
[00:48] <wgrant> StevenK: Right, I'd grep around for egistrant and upervisor and ecurity and delete lots of stuff :)
[00:48] <StevenK> wgrant: egistrant is hampered by branch and product registrant tests
[00:49] <wgrant> True
[00:49] <wgrant> But still
[00:51]  * StevenK greps for ecurity and drowns in rSP calls
[00:53] <StevenK> lib/lp/blueprints/browser/specification.py:        text = 'Change privacy/security'
[00:53] <wgrant> Huh
[00:59] <StevenK> wgrant: I'm quite tempted to just leave bug-private-by-default.txt alone and it can die when the rest does.
[01:00] <wgrant> StevenK: That's the plan
[01:00] <wgrant> The thing it still tests is the only situation in which the bug supervisor should still be subscribed
[01:00] <StevenK> Then I can't find anything else, or it has been drowned out by the noise.
[02:23] <StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/remove-registrant-tests/+merge/123207
[02:23] <wallyworld> StevenK: too late
[02:26] <StevenK> wallyworld: Indeed, thanks.
[02:26] <wallyworld> np
[02:50]  * StevenK peers at the end test in lib/lp/bugs/stories/bugtask-searches/xx-advanced-upstream-pending-bugwatch.txt
[02:51] <StevenK> Does anyone *actually* do that?
[03:01] <wgrant> Right, that's why it is how it is now
[03:01] <wgrant> Curtis argues not
[03:02] <wgrant> It used to be the case that +bugs-index avoided showing the list, but you could hack your way through to +bugs to get the listing regardless of configurtaion
[03:03] <wgrant> But those pages are merged now
[03:07] <lifeless>  * 19317 Time Outs
[03:08] <lifeless> twitch
[03:08] <lifeless> when do you guys start on maintenance ?
[03:09] <wgrant> lifeless: Monday, allegedly
[03:09] <wgrant>     12938 /    0  Archive:EntryResource:getPublishedBinaries
[03:09] <wgrant> wat
[03:09] <wgrant> I blame ev
[03:09] <wgrant> I think
[03:10] <lifeless> could be
[03:11] <wgrant> HTTP_USER_AGENT: lazr.restfulclient 0.12.0; oauth_consumer="pkgme-binary"
[03:11] <wgrant> jml
[03:12] <wgrant> Trigram index on BPN.name will probably fix that instantly
[03:12] <wgrant> But I wonder if they're deliberately using exact_match=False
[03:14] <wgrant> Ah, it's also still querying on BPR.bpn
[03:15] <lifeless> see also ev's code
[03:15] <lifeless> forwarded you mail
[03:16] <wgrant> Um
[03:16] <wgrant> Do we really have a second service named 'poppy'?
[03:21] <wgrant> There we go, got that query down to 10ms
[03:21] <wgrant> From 4900ms
[03:21] <wgrant> Launchpad is optimised :)
[03:22] <lifeless> \o/
[03:22] <wgrant> Oh good
[03:22] <wgrant> The backup failed today
[03:22] <wgrant> So we can create the indices now :)
[03:27] <lifeless> again?
[03:27] <wgrant> Yeah
[03:27] <wgrant> It's almost like the slave feedback thing isn't working
[03:27] <lifeless> stub will be miffed :)
[03:27] <wgrant> But I thought it was
[03:28] <lifeless> it has an upper bound IIRC
[03:28] <wgrant> Yeah
[03:29] <stub> I suspect it happens when the replication connection drops. It reconnects, but the master has already moved on and started cleaning crap up
[03:29] <stub> I'll check the logs when I'm back upstairs
[03:29] <lifeless> stub: perhaps we should backup on the master again ?
[03:30] <lifeless> stub: identical bloatwise
[03:30] <wgrant> And we have the CPU
[03:33] <wgrant> The indices won't immediately fix either consumer's performance issues, but they'll fix the fixed pkgme queries from 200ms to 10ms
[03:33] <wgrant> and the 5000->200 optimisation will land shortly :)
[03:34] <lifeless> lol
[03:34] <wgrant> Hm?
[03:34] <lifeless> 15:34 -!- stub [~stub@canonical/launchpad/stub] has quit [Ping timeout: 268 seconds]
[03:35] <wgrant> Maybe he's going back upstairs :)
[03:35] <lifeless> I suspect he walked of upstairs right after
[03:35] <lifeless> 15:29 < stub> I'll check the logs when I'm back upstairs
[03:35] <lifeless> and didn't see anything we said after that
[03:35] <wgrant> Yep
[03:49] <wgrant> 13:29:20 < stub> I'll check the logs when I'm back upstairs
[03:49] <wgrant> 13:29:57 < lifeless> stub: perhaps we should backup on the master again ?
[03:49] <wgrant> 13:30:02 < lifeless> stub: identical bloatwise
[03:49] <wgrant> 13:30:22 < wgrant> And we have the CPU
[03:55] <stub> Yeah, that is the backup plan, so to speak :)
[03:55] <stub> Chokecherry is preferred because it has more disk
[03:55] <wgrant> Ah, indeed
[03:56] <wgrant> stub: https://code.launchpad.net/~wgrant/launchpad/bpn-spn-trgm-index/+merge/123208 is a nice difficult one for you
[03:56] <stub> Cool. I think I suggested that to someone else recently
[03:56] <wgrant> I meant to do it months ago after the first trigram trial, but didn't get around to it until now
[03:57] <stub> And for bikeshedding, should we use a different suffix for trigram indexes?
[03:58] <stub> Down to one test fail on my db policy updates branch
[04:01] <wgrant> stub: Possibly. name tends to be (part of) a _key usually, so there hasn't been a conflict until now
[04:01] <wgrant> But __trgm or something would work too, I suppose
[04:01] <stub> yeah, just thinking hypotheticals
[04:02] <stub> Every naming convention I know for dbs breaks down somewhere, I'm not too fussed.
[04:03]  * wgrant checks ALTER INDEX ... RENAME lock requirements
[04:03] <StevenK> wgrant: So should I drop that test completly?
[04:03] <wgrant> StevenK: Which?
[04:04] <StevenK> wgrant: "[13:01] < wgrant> Right, that's why it is how it is now" and so on
[04:04] <wgrant> StevenK: Ah
[04:04] <wgrant> StevenK: Well
[04:04] <wgrant> StevenK: Decide whether the use-case is worth it
[04:05] <wgrant> StevenK: If it's not, delete the test that says it is
[04:05] <wgrant> Bah, renaming indices appears to require an exclusive lock
[04:05]  * wgrant just creates the new ones with good names
[04:05] <StevenK> Well, there's a critical regression that says it isn't.
[04:05] <StevenK> So I don't know.
[04:05] <wgrant> Ah, now I think I remember
[04:05] <wgrant> There's a link
[04:05] <wgrant> In a portlet
[04:05] <wgrant> To that list
[04:06] <wgrant> "XX bugs need forwarding upstream" or something like that
[04:06] <StevenK> So I can close the critical by removing functionalility or by replying and saying it is used for this feature.
[04:07] <wgrant> BugsInfoMixin.pending_bugwatches_url
[04:07] <wgrant> Right
[04:07] <wgrant> This changed when buglistings merged +bugs-index and +bugs
[04:07] <StevenK> Ahh
[04:07] <StevenK> Which might be where the confusion is coming from.
[04:08] <StevenK> I'm tempted to just close the bug saying it isn't a regression.
[04:09] <lifeless> how many tests does LP have today ?
[04:09] <StevenK> 17453 or thereabouts
[04:35] <wgrant> stub: I've renamed the indices. Can you throw them at prod?
[04:37] <stub> k
[04:45] <stub> wgrant: done
[04:45] <wgrant> stub: Thanks.
[04:45] <wgrant> stub: Can you also do it to qastaging?
[04:46] <wgrant> Since it won't happen automagically
[04:48] <stub> done
[04:48] <wgrant> Great
[05:22]  * StevenK can't work out what is touching IBug.date_last_updated when someone subscribes or unsubscribes.
[05:23] <StevenK> OH. Via ZCML.
[05:23]  * StevenK goes to review his lunch.
[05:23] <wgrant> Yeah, Bugs uses a fair few subscribers
[05:25]  * nigelb wonders what would happen if StevenK gave r- for lunch.
[05:27] <StevenK> Hmmm, that still doesn't explain it.
[05:30] <StevenK> And I doubt I can get a useful calltrace out of the function itself :-(
[05:32] <wgrant> The stacktrace should be fine
[05:38] <StevenK> Hm, calling bug.subscribe() and bug.unsubscribe() don't trigger it.
[05:41] <wgrant> StevenK: Where are you calling them?
[05:42] <StevenK> Directly
[05:44] <StevenK> wgrant: Based on the bug filed, I thought the model functions might do it. But they don't.
[05:49] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/faster-binary-search/+merge/123213 ← +86/-228 query optimisation
[05:49] <wgrant> If you have time today
[05:52] <StevenK> wgrant: Your indenting in lib/lp/archivepublisher/publishing.py looks wrong
[05:53] <wgrant> StevenK: It's arguable. PEP 8 suggests extra indentation like that when it would otherwise be visually ambiguous
[05:55] <StevenK> wgrant: r=me
[05:55] <wgrant> Thanks
[05:56] <StevenK> And grepping for date_last_updated doesn't help either
[05:56] <StevenK> Clearly, it's updated by magic.
[05:59] <StevenK> Subscribing and unsubscribing does *not* trigger an update of
[05:59] <StevenK> IBug.date_last_updated.
[06:01] <wgrant> lib/lp/bugs/configure.zcml:        handler="lp.bugs.subscribers.buglastupdated.update_bug_date_last_updated"/>
[06:01] <wgrant> is a bit suspicious
[06:01] <StevenK> Oh, why?
[06:01] <wgrant> Hm, but it's not on IBugSubscription creation
[06:01] <StevenK> Yes
[06:01] <wgrant> So possibly it's the ObjectModifiedEvent from updating the subscriber or affected count or something?
[06:03] <StevenK> I thought they just backed onto BugSubscription and didn't hit Bug?
[06:04] <StevenK> And I thought affects me didn't subscribe
[06:04] <wgrant> Some things are denormed
[06:04] <wgrant> +affectsmetoo doesn't subscribe, no
[06:04] <wgrant> But the operations are performed together
[06:04] <StevenK> I suspect +affectsmetoo will trigger date_last_updated
[06:05] <StevenK> wgrant: But by what? If stuff was denormed, you'd think subscribe() would perform it?
[06:05] <wgrant> Maybe
[06:05] <wgrant> I don't think it's a trigger
[06:05] <wgrant> I hope it's not a trigger
[06:07] <StevenK> Not that I can see
[06:07] <wgrant> StevenK: I wonder if it's just lazr.restful firing an ObjectModifiedEvent after subscribe() is called
[06:09] <StevenK> wgrant: The existing test calls notify(ObjectCreatedEvent(subscription))
[06:10] <wgrant> I mean an ObjectModifiedEvent(bug)
[06:10] <wgrant> I don't know if it does it implicitly on named ops
[06:10] <wgrant> But it might well do so
[06:18] <StevenK> Hmm, API scripts really don't want to talk to dev
[06:18] <wgrant> There's an environment variable for that
[06:19] <StevenK> LP_DISABLE_SSL_CERTIFICATE_VALIDATION?
[06:19] <wgrant> Yeah
[06:20] <StevenK> wgrant: http://pastebin.ubuntu.com/1190284/
[06:20] <wgrant> StevenK: Make sure you're using a modern launchpadlib
[06:20] <wgrant> eg. run with bin/py
[06:21] <StevenK> Oooh
[06:22] <StevenK> RARGH
[06:22] <StevenK> IT DOES UPDATE
[06:22] <StevenK> LAZR.RESTFUL!
[06:23] <StevenK> wgrant: http://pastebin.ubuntu.com/1190287/
[06:23] <wgrant> Right
[06:23] <wgrant> That makes sense
[06:23] <wgrant> So you need to fix the subscriber
[06:24] <wgrant> To not subscribe to subscribers
[06:24] <wgrant> (currently it sets date_last_updated unconditionally; it may want to verify some attributes of the event first)
[06:25] <StevenK> Right
[06:26] <StevenK> I should have guessed, since lazr.restful calls ObjectModifiedEvent on the object you called the method on
[06:30] <StevenK> Right, bug updated
[06:44] <wgrant> StevenK: Heh
[06:44] <wgrant> StevenK: Did you really run something that only deleted tests through ec2?
[06:45] <StevenK> Hm, that was a bit silly
[06:45] <StevenK> Oh well
[07:55] <jml> wgrant, lifeless: if there's something you want changed about our code, do let us know. <https://bugs.launchpad.net/pkgme-devportal/+filebug> is a good place.
[07:57] <wgrant> jml: Do you know if you're deliberately using exact_match=False in the getPublishedBinaries call? That does substring matching on the name, which is a little slower and may return excessive results.
[07:57] <jml> wgrant: good question. oddly enough, james_w sent an email about that to me yesterday...
[07:58]  * jml pages in
[07:58] <wgrant> exact_match=False is currently very slow, but so is exact_match=True. Both will be fast on Monday, but exact_match=True will obviously still be a little faster and probably more correct.
[08:02] <jml> ah
[08:03] <jml> "I think this might have had something to do with using exact_match=False when looking for publications, so it was doing fuzzy package name matching. I don't know why it was doing that, so I removed it. It should now just iterate over all publications for configured architectures for the given binary package name."
[08:03]  * jml rolls up sleeves and does code reviews.
[08:04] <wgrant> https://bugs.launchpad.net/launchpad/+bug/1047176 is the slowness issue
[08:04] <_mup_> Bug #1047176: Archive.getPublishedBinaries is terribly slow <timeout> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/1047176 >
[08:07] <wgrant> You're currently getting somewhere around 10000 timeouts a day, so this will hopefully improve things
[08:07] <jml> ah right.
[08:07] <jml> it's a lp:udd instance
[08:07] <jml> so it's hard to tell
[08:08] <wgrant> Ah
[12:46] <wallyworld> sinzui: hi, i have a question about the product licence widget
[12:50] <sinzui> yes?
[12:50] <wallyworld> i have gobs of javascript from the tal into it's own module, and replaced all the custom expander code with standard collapsible elements. but it appears to me that the code which handles source_package_release and allow_pending_license is obsolete since i can't see how or where these attributes on LicenseWidget are ever set
[12:51] <wallyworld> i also have the hidden stuff working for bots and screen readers etc
[12:52] <wallyworld> it turns out yui convenientsly adds a yu3-javascript class to the html element if javascript is enabled
[12:52] <sinzui> Register the project from a (disto) source package
[12:52] <sinzui> There are 4 places to register a project:
[12:53] <sinzui> projects/+new
/+newproject
/+index and <sp>/index
[12:53] <wallyworld> ok. i only knew about the first way
[12:54] <sinzui> wallyworld, https://launchpad.net/ubuntu/quantal/+source/cryptkeeper
[12:55] <sinzui> https://launchpad.net/ubuntu/+source/cryptkeeper is really ^. It chooses the current SP
[12:55] <wallyworld> so you mean the "Register Upstream Project" link?
[12:55] <sinzui> yes
[12:56] <sinzui> It prepoulates the form and adds the copyright file to help with choosing licenses
[12:56] <wallyworld> ok. i'll have a play around on qas and see how it all behaves. thanks
[12:56] <wallyworld> i am pretty sure i have it all working fine, i just want to check these extra cases
[12:56] <wallyworld> i had hard coded stuff into the projects/+new to initially test
[12:57] <sinzui> Oh, I got one url wrong https://launchpad.net/launchpad-project/+newproduct is correct
[12:57] <wallyworld> ok
[12:58] <wallyworld> with all the standard collapsible / expander stuff uses, the licence javascript shrinks dramatically in size. it was all very old code
[12:58] <sinzui> Yes, it was barry's first js written just a few months after we started using YUI
[12:59] <sinzui> I think keyboard users hate the form because you can tab into the a hidden license
[13:00] <wallyworld> yeah, it was all that was possible in the day but years later we have better infrastructure. i'll check the tabbing issue to see that it's gone
[13:00] <sinzui> well
[13:01] <sinzui> I reviewed a lot of this code in 2009. I decided then and there that I will never write a windmill test or repeat the mistake of inline js
[13:02] <sinzui> I used yui-test...then had to argue that my tests were better then the windmill site
[13:02] <sinzui> shite
[13:03] <wallyworld> i didn't know yuitest at first - my first tests of this nature were in windmill. i am glad it's gone for sure
[13:03] <wallyworld> sadly, people all over still tend to write inline js. especially in the world of jsp, php etc
[13:05] <deryck> Morning, all.
[13:05] <rick_h_> morning
[13:06] <rick_h_> wallyworld: not enough shooting taking place for violaters :P
[13:06] <wallyworld> rick_h_: too soon after all the recent happenings over there?
[13:07] <rick_h_> they keep hitting the wrong people. Missing the JS violaters
[13:07] <wallyworld> hah
[13:07]  * wallyworld doesn't understand th US gun culture
[13:14] <lifeless> s/gun //
[13:14] <wallyworld> well...
[13:15] <wallyworld> that's a beer conversation
[13:15] <lifeless> :)
[13:15] <lifeless> so, week after next then
[13:15] <wallyworld> yes, you be in brisbane?
[13:15] <lifeless> likely to be
[13:15] <wallyworld> cool. we'll have to organise dinner or somwthing
[13:16] <lifeless> we're getting an ex-weta dude in to talk maas use cases.
[13:16] <lifeless> I'll be there to help extract maximum knowledge
[13:16] <wallyworld> ok. is this a consultant?
[13:20] <lifeless> yes
[13:22] <wallyworld> well, when you know dates let's get something organised
[13:24] <lifeless> will do
[13:24] <lifeless> thats pending flacoste and the consultant making sweet sweet arrangements.
[13:25] <wallyworld> ok
[14:22] <abentley> rick_h_: Do you have time for a UI question?
[14:22] <rick_h_> abentley: sure thing
[14:23] <abentley> rick_h_: So, only products are going to allow blueprints to have proprietary information types.  All other kinds of blueprints are necessarily PUBLIC.
[14:23] <abentley> rick_h_: We have to display the information_type selector when creating a bluprint that might be associated with a product.
[14:24] <abentley> rick_h_: should we also display the information_type selector if it won't be associated with a product?
[14:25] <rick_h_> I'd say no, I'd hide the field unless a product is selected and if the product is selected we'd show the field, default to the products information type and maybe do a flash green to show it's there
[14:25] <rick_h_> no sense adding UI that the user can't effect and the banner indicated public/private already so showing it is duplicate information
[14:29] <abentley> rick_h_: Okay.  I'm inclined not to show information_type dynamically-- just keep it on the "https://blueprints.launchpad.net/specs/+new" page and the blueprint-for-product page.
[14:30] <rick_h_> abentley: ok, then I'd probably at least disable/enable the field based on the "For"?
[14:30] <abentley> rick_h_: Yes, that's what I mean.
[14:30] <rick_h_> ah ok cool
[14:31] <abentley> rick_h_: would you hide the picker if you knew the project policy supported only one value?
[14:32] <rick_h_> I think so since the large majority of use cases don't need to know about the data
[14:33] <rick_h_> it's like showing the current default information types for a project in a portlet, only show that portlet if one of the apps are non-public.
[14:34] <abentley> rick_h_: Cool.
[15:05] <abentley> deryck: I find it confusing that getAllowedInformationTypes does not consider getBranchSharingPolicies or getBugSharingPolicies.
[15:06] <deryck> abentley, I'm in all that space myself now…. let me look closely again now....
[15:16] <deryck> abentley, yeah, I find it weird, too.  Now that I get my head around it.  Sorry to be so slow.
[15:16] <deryck> abentley, seems like it would save a query, too, unless the method is doing more than it seems to me.
[15:22] <abentley> deryck: So, silly me, I assumed that Branch.getAllowedInformationTypes used ISharingService.getAllowedInformationTypes.  Instead, it uses IBranchNamespacePolicy.policy.getAllowedInformationTypes()
[15:24] <deryck> ah, I was just thinking of the SharingService method.
[15:25] <abentley> deryck: For bugs, though, the BugSharingPolicy doesn't seem to be used, just Pillar.getAllowedInformationTypes().
[15:26] <deryck> I wonder why they're different?
[15:29] <sinzui> deryck, abentley Pillar.getAllowedInformationType() uses the policy and understand that the types can be in transition
[15:30] <abentley> sinzui: Oh, my bad, that's Pillar.getAllowedBUGInformationTypes.