[00:46] <StevenK> wgrant: Do I have to drop indicies that reference a column before dropping it or will Postgres just deal?
[00:46] <wgrant> StevenK: postgres will drop any indices that involve the column
[00:46] <wgrant> StevenK: This can sometimes be undesirable, in the case of compound indices
[00:46] <wgrant> So be careful
[00:47] <StevenK> product is fine, just a partial index, no compounds
[00:48] <StevenK> distribution is also fine, one index, no compounds
[01:10] <wgrant> StevenK: Right
[01:20] <StevenK> wgrant: make newsampledata seems to ignore the column drop
[01:21] <wgrant> StevenK: You've applied the patch to launchpad_dev and launchpad_ftest_playground?
[01:23] <StevenK> Hmm, my apply ... didn't.
[01:23]  * StevenK stabs it harder
[01:30] <wgrant> StevenK: Fail
[01:30] <wgrant> StevenK: Instead of subscribing the security contact or the maintainer, you now unconditionally subscribe the maintainer
[01:30] <wgrant> That block should go
[01:30] <wgrant> Both of them
[01:31] <wgrant> 1121+ getattr(info, 'bug_supervisor_tasks').append(value)
[01:31] <wgrant> That can be simplified
[01:35] <StevenK> wgrant: http://pastebin.ubuntu.com/1160033/
[01:36] <wgrant> what the driver
[01:36] <wgrant> Oh
[01:36] <wgrant> That's during the transition
[01:36] <wgrant> Hm
[01:38] <wgrant> I think that diff is correct
[01:38] <wgrant> But I was never a fan of the unsubscription rules
[01:43] <StevenK> wgrant: Thanks, I've commited and pushed that bit
[02:12]  * StevenK stabs the branch scanner for being terrible
[02:32] <StevenK> Dear branch scanner, DIAF.
[02:47] <StevenK> wgrant: Is https://code.launchpad.net/~stevenk/launchpad/db-destroy-security-contact cursed?
[02:48] <wgrant> StevenK: Let me consult with my colleagues
[02:49] <wgrant> StevenK: The spirits have indeed placed a curse upon it
[02:49] <wgrant> Rename and repush
[02:56]  * StevenK sacrifies wallyworld to the branch scanner.
[02:56] <wallyworld> no not me, i've also had the same issues
[02:56] <wallyworld> so i vote to sacrifice wgrant
[02:56] <StevenK> He's useful to have around.
[02:57] <wallyworld> but he's a young virgin and the gods like those
[02:57] <StevenK> ROFL
[02:57] <wallyworld> quotes page :-D
[02:58] <StevenK> wallyworld: It looks like threatning to sacrifice you was enough
[02:58] <wallyworld> yay
[02:59] <wgrant> Heh
[02:59] <wgrant> StevenK: Did you create an early MP or subscription or anything on that branch?
[03:00] <wgrant> Before it had first scanned?
[03:00] <StevenK> wgrant: Nope
[03:00] <wgrant> :(
[03:00] <StevenK> I didn't touch it for fear of a curse.
[03:00] <StevenK> And it got cursed anyway
[04:29] <StevenK> wgrant: Hahahaha
[04:30] <StevenK> wgrant: You added POLICY_ALLOWED_TYPES to code/model/branchnamespace.py for branches and bugs/interfaces/bugtarget.py for bugs.
[04:31] <wgrant> StevenK: Is that a problem?
[04:31] <wgrant> Their meanings are different
[04:31] <wgrant> And they were private until you came along
[04:33] <StevenK> wgrant: I was amused at the model vs interface split
[04:33] <wgrant> Ah, right
[04:33] <wgrant> I wasn't quite sure where to put the latter
[04:33] <wgrant> Since it's not used by model.bugtarget
[04:33] <wgrant> But by the things that inherit it
[04:34] <wgrant> Whereas for BranchNamespace it's only used by that class and tests.
[04:34] <StevenK> And now a garbo job
[05:24] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/remove-unused-sharing-garbo/+merge/120698
[05:26] <wgrant> StevenK: The RAM, oh god, the RAM
[05:26] <wallyworld_> StevenK: just running out for school pickup, can look when i get back
[05:44] <StevenK> wgrant: What do you think we should do to get the used or even better, the unused APs?
[05:45] <wgrant> StevenK: You could search for artifacts for each and use is_empty
[05:45] <wgrant> Means a couple of extra queries
[05:45] <wgrant> But meh
[05:55] <StevenK> Isn't apas = getUtility(IAccessPolicyArtifactSource).findByPolicy(
[05:55] <StevenK> Already doing so?
[05:56] <StevenK> And looping over it is bad?
[05:58] <wgrant> StevenK: That's finding all the APAs, not just the APAs' distinct policies
[05:58] <wgrant> launchpad_dogfood=# SELECT policy, COUNT(*) FROM accesspolicyartifact GROUP BY policy ORDER BY COUNT(*) DESC LIMIT 20;
[05:58] <wgrant>  policy | count
[05:58] <wgrant> --------+-------
[05:58] <wgrant>     137 | 45598
[05:58] <wgrant>   68775 | 10233
[05:59] <StevenK> Yeah, I see what you mean.
[06:01] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/moar-auditor/+merge/120706
[06:02] <wgrant> StevenK: Why's lp.services.auditor.server not in testing/fixtures/something?
[06:02] <StevenK> I was following txlongpoll's pattern
[06:10] <wgrant> StevenK: Antipattern
[06:11] <StevenK> Still
[06:21] <StevenK> wgrant: Back to the garbo job: http://pastebin.ubuntu.com/1160294/
[06:26] <wgrant> unused_aps = [ap for ap in candidate_aps if apa_source.findByPolicy([ap]).is_empty()]?
[06:38] <StevenK> wgrant: http://pastebin.ubuntu.com/1160307/
[06:39] <wgrant> StevenK: I'd tend to wrap just before the 'if' for cleanliness
[06:41] <StevenK> wgrant: http://pastebin.ubuntu.com/1160309/
[06:42] <wgrant> StevenK: Also, unless the two args to both get() calls don't fit on one line, please wrap before the first arg. But apart from that it looks excellent.
[06:42] <wgrant> And I'm glad access is no longer policing.
[06:43] <StevenK> wgrant: http://pastebin.ubuntu.com/1160312/
[06:43] <StevenK> Yes, access made constable.
[06:57] <StevenK> wgrant: No opinion?
[07:00] <wgrant> StevenK: Looks good
[07:01] <StevenK> wgrant: Thanks, pushing it up.
[07:21] <StevenK> wgrant: Diff *finally* updated
[07:26] <adeuring> good morning
[07:33] <StevenK> wgrant: No approval for me? :-(
[07:36] <wgrant> StevenK: Could you a docstring to the TunableLoop and perhaps some comments describing what it's doing and why?
[07:36] <wgrant> Apart from that it's fine
[07:37] <wgrant> I accidentally the whole thing, but anyway
[08:27] <cjwatson> Spads: Hi.  Since the DC move, we've been short all the dogfood.lp builders, and rather a lot of Launchpad revisions are now blocked on a single revision that requires dogfood build QA.  There's been some insinuation that we might be able to get king for a while, but I'm assuming that's non-trivial since it hasn't happened yet; is there any chance we might be able to temporarily steal a production PPA builder for the ...
[08:27] <cjwatson> ... task?  It should only take maybe half an hour.
[08:28] <cjwatson> Err, why did that end up on #lp-dev
[08:28] <cjwatson> Given that Spads isn't here
[08:28]  * cjwatson moves to a cleverer channel
[12:35] <BjornT> is something wrong with qastaging? i get timeouts (OOPS-64204c86af12c8a1d8c6fa597795a531) and oopses (OOPS-307f7eabfe6fed73cfa46b6dbb3b21d5) all the time
[12:36] <rick_h_> BjornT: the db on there isn't primed up with requests and it times out a lot more often
[12:36] <rick_h_> BjornT: are you trying to qa something or just tinker with disposable data? There are some smaller projects that tend to work ok for testing purposes
[12:37] <wgrant> BjornT: Project group bug listings on qastaging... good luck with that
[12:37] <wgrant> They're slow on production
[12:37] <wgrant> And not indexed well
[12:37] <wgrant> I'd try something else, or a very very small project group :)
[12:38] <BjornT> rick_h_: i'm trying out an api script of mine. i guess i could try on a smaller project. although, i get oopses just looking at bugs as well (OOPS-6bdbc2384d11ecd88e64f635d5162828)
[12:39] <wgrant> Hm
[12:39] <wgrant> BjornT: Oh, that one's an OOPS, not a timeout
[12:39] <wgrant> qastaging lacks a DB patch
[12:40] <czajkowski> wgrant: any update on the DB patch on qastaging ?
[13:28] <rick_h_> abentley: ping
[13:28] <abentley> rick_h_: HI.
[13:44] <deryck> adeuring, abentley, rick_h_ -- hey there.  Everyone good to join now?
[13:45] <rick_h_> deryck: rgr
[13:45] <adeuring> deryck: sure
[13:45] <abentley> deryck: yup
[15:31] <sinzui> jcsackett: I am having terrible connectivity issues
[15:31] <sinzui> jcsackett: can you rollback cjwatson's rev that blocks deployment: http://lpqateam.canonical.com/qa-reports/deployment-stable.html
[15:34] <wgrant> BjornT: qastaging has had the missing column added, so it should have stopped OOPSing. But I'm afraid there'll still be lots of timeouts
[15:36] <mpt> Hey, does the Launchpad code include a PPA picker in the same way that it has a person picker and a project picker?
[15:37] <sinzui> no
[15:37] <sinzui> mpt: no ppa-picker
[15:37] <wgrant> There is actually a PPA picker
[15:37] <wgrant> It's very basic
[15:38] <sinzui> roe recipes?
[15:38] <sinzui> for
[15:38] <wgrant> Precisely.
[15:38] <sinzui> sorry, network and stress make my only tpy in Curtisese
[15:38] <wgrant> The "Daily build archive" field on SourcePackageRecipe:+index uses it
[15:40] <mpt> wgrant, basic in what way? That it lets you choose from only your own PPAs?
[15:41] <wgrant> mpt: And your teams'
[15:41] <wgrant> mpt: Without searching
[15:41] <cjwatson> Is that the same as the terrible list drop-down on +copy-packages?
[15:41] <wgrant> cjwatson: It's arguably worse
[15:41] <wgrant> although it at least shows the actual name
[15:41] <wgrant> Not just the displayname
[15:42] <wgrant> But it's paginated
[15:42] <cjwatson> (Which is ambiguous if displaynames ever collide across teams)
[15:42] <wgrant> And unsearchable
[15:42] <mpt> wgrant, perfect. (For the purpose I'm thinking of, at least. Not necessarily Colin's.)
[15:42] <cjwatson> +copy-packages would be improved by having to toggle in the PPA name in octal
[15:42] <wgrant> Indeed
[15:42] <wgrant> It's probably from back in the good old days when PPA names were immutable.
[15:43] <cjwatson> (Also, IIRC it defaults to the copy target being the same PPA and same series.)
[15:43] <wgrant> (although that still would have run into the duplicate person display name issue)
[15:45] <jcsackett> sinzui: i can.
[15:45] <sinzui> thank you.
[15:46] <sinzui> I am switching dns servers at this moment so I was not certain I missed your reply
[15:50] <jcsackett> sinzui: should it be marked qa-bad bad-commit &c?
[15:51] <jcsackett> (the bug on said rollback branch)
[15:51] <sinzui> jcsackett: yes, for our purposes
[15:51] <jcsackett> sinzui: ok.
[15:51] <jcsackett> i'll tag it as well.
[15:52] <sinzui> jcsackett: we cannot prove it is safe to release so we do not want it to go out with the sharing code
[15:53] <jcsackett> dig.
[15:57] <jcsackett> sinzui: two more things. do you want to look at the MP, or are you cool with rs=me, and do we know if a rollback of this branch is safe to bzr lp-land or does it need to play on ec2?
[15:58] <cjwatson> Should be safe to lp-land.
[15:58] <sinzui> cjwatson: thank you
[15:58] <cjwatson> Nothing else since then has touched related code.
[15:59] <sinzui> jcsackett: use rs=you since cjwatson is the authority in this case
[15:59] <jcsackett> cjwatson: thanks.
[15:59] <jcsackett> sinzui: got it.
[16:08] <jcsackett> sinzui: it's off.
[16:09] <sinzui> thank you very much
[17:13] <sinzui> jcsackett: cjwatson: buildbot now sees my restore of rev 15823. I think everything is now good. I have some hope another branch will land in the next few hours to justify the  build we have queued in build bot.
[17:15] <cjwatson> Phew.
[19:12] <abentley> deryck: I'm the OCR.  Do you have the time to review https://code.launchpad.net/~abentley/launchpad/upgrade-badly-stacked/+merge/120854 ?
[19:13] <deryck> abentley, sure
[19:23] <deryck> abentley, heh.  "I have a LOC credit of 1860."  Now you're just showing off there. ;)
[19:23] <abentley> deryck: :-)
[19:50] <sinzui> I believe wgrant is -26,000 LoC. I an -10,000 LoC since we started Disclosure
[19:50] <sinzui> PS. The squad is as whole is +10,000 because of the new features
[19:52] <elmo> is there a black market in LoC?
[19:53] <elmo> if not, should I file a bug about implementing one in LP itself?
[19:53] <abentley> elmo: I can hook you up.  There's some code that I know is going obsolete soon :-)
[20:13] <deryck> It's like a bunch of MMO gold farmers up in here.
[20:13] <deryck> abentley, r=me, looks good.
[20:13] <abentley> deryck: thanks.
[20:18] <sinzui> fab, I was going to as if that branch needed a review
[22:57] <StevenK> wgrant: http://pastebin.ubuntu.com/1161748/
[23:46] <StevenK> wgrant, wallyworld: What kind of sanity check does reconcile_access_for_artifact need?
[23:47] <wallyworld> StevenK: when adding a new bug target, the target project may not have the relevant access policy defined
[23:48] <wallyworld> so a check needs to be done that pillar count == policy count (in simplistc terms)
[23:48] <wallyworld> wgrant says we should just raise an exception in that case
[23:48] <StevenK> >= surely
[23:48] <wallyworld> yes
[23:49] <wallyworld> other way round perhaps
[23:49] <StevenK> Ah, no, we need to make sure that each pillar has an AP.
[23:49] <StevenK> And if no, croak
[23:49] <wallyworld> each pillar needs to have an access policy for the relevant bug information type
[23:55] <wgrant> wallyworld, StevenK: I think an exact match is best
[23:56] <wallyworld> reason being?
[23:57] <wgrant> There should be exactly one for each
[23:57] <wgrant> If there isn't, something is wrong
[23:57] <wgrant> If something's wrong, better to crash than corrupt
[23:57] <wgrant> (eg. a private junk branch is being transferred to a public team somehow)
[23:58] <wallyworld> ok, be interesting to see how many times we need to raise an exception in practice