[00:32] <lifeless> matsubara-afk: the timeout feature flag was harder than anticipated, its all landed now, though
[00:42] <wgrant> lifeless: Julian wrote a faster query last night, but it was slightly wrong. Could you try http://paste.ubuntu.com/506074/ and see if it doesn't take 10 minutes?
[00:43] <lifeless> hmmm tmp tables :)
[00:43] <lifeless> :( I mean
[00:44] <wgrant> Yes.
[00:44] <wgrant> It's a similar optimisation to the one we use in the publisher.
[00:44] <wgrant> Which cuts 2.5 minutes down to less than two seconds.
[00:44] <lifeless> 6 seconds to populate the temp table
[00:44] <lifeless> should be able to express it directly. Nevertheless, if it works, it works.
[00:44] <wgrant> One would think so.
[00:45] <lifeless> perhaps the select needs a supersededby IS NULL in there ?
[00:45] <wgrant> The subselect?
[00:45] <lifeless> is supersededby indexed ?
[00:45] <wgrant> No.
[00:45] <lifeless> yes, the subselect
[00:45] <wgrant> It's valid for something to be superseded by something that's also itself superseded.
[00:46] <wgrant> It appears to be indexed.
[00:46] <lifeless> yes, but we don't care about those do we?
[00:46] <lifeless> only the tip of the chain
[00:47] <wgrant> We do care about those. We are looking for things which should not be superseded but are.
[00:47] <wgrant> It doesn't matter if the thing that superseded them is superseded or not -- it should not have superseded them.
[00:47] <lifeless> ok
[00:48] <wgrant> The query is still going?
[00:48] <lifeless> yes
[00:48] <wgrant> :(
[00:49] <wgrant> I guess I did just increase the data size by several times.
[00:55] <lifeless> 3662 rows
[00:55] <lifeless> 465000.849 ms
[00:56] <wgrant> Comfortingly an identical number to yesterday's.
[00:57] <wgrant> Thanks.
[00:57] <lifeless> de nada
[00:58] <wgrant> Hmmm
[00:58] <wgrant> http://paste.ubuntu.com/506096/ might be less crap.
[01:08]  * StevenK grumbles about http://paste.ubuntu.com/506100/
[01:09] <wgrant> StevenK: bin/kill-test-services
[01:09] <wgrant> Or was that on ec2?
[01:09] <wgrant> Hm, looks ec2.
[01:09] <StevenK> wgrant: On ec2, yes
[01:09] <wgrant> Sad.
[01:10] <wgrant> I had a similarly opaque error on one of my runs this morning.
[01:10] <wgrant> But it was completely different.
[01:10] <lifeless> well the librarian is definitely gone :P
[01:11] <lifeless> wgrant: 21 seconds to make the temp table
[01:22] <lifeless> 3662 rows
[01:22] <lifeless> 121149.515 ms
[01:22] <wgrant> Aha!
[01:22] <wgrant> Much better. Thanks.
[01:39] <wallyworld> lifeless: what's SOP for turning on sql trace for local debugging? i can add "from storm.tracer import debug; debug(True)" to bin/run (for example). is there cmd line arg i can use?
[01:41] <lifeless> LP_SQL_DEBUG=1
[01:41] <lifeless> LP_SQL_DEBUG_EXTRA=1 to get backtraces
[01:41] <wallyworld> lifeless:  excellent. thanks
[01:41] <lifeless> those are environment variables
[04:09] <lifeless> wgrant: librarian fail
[04:26] <wgrant> lifeless: Hm?
[04:27] <lifeless> see email
[04:30] <wgrant> lifeless: So, that's two attempts that have failed in two different spurious ways.
[04:30] <wgrant> Awesome.
[04:39]  * StevenK peers at http://ppa.launchpad.net/launchpad/ppa/ubuntu/dists/lucid/main/binary-amd64/Packages
[04:39] <StevenK> No launchpad-dependencies at all? WTF?
[04:40] <wgrant> Heh, is this what I think it is?
[04:40]  * wgrant checks.
[04:40] <lifeless> wgrant: its almost certainly my layers work
[04:41] <lifeless> wgrant: we'll need to figure out whats up
[04:42] <StevenK> lifeless: Does that mean http://paste.ubuntu.com/506100/ is probably you too?
[04:43] <lifeless> wow, Product:+bugtarget-portlet-bugfilters-stats is unhappy
[04:43] <lifeless> stub: ^
[04:44] <wgrant> StevenK: I suspect you have found one of the few PPA cases of bug #653382....
[04:44] <_mup_> Bug #653382: BinaryPackagePublishingHistory._getOtherPublications fails to restrict the distroseries context <Soyuz:In Progress by wgrant> <https://launchpad.net/bugs/653382>
[04:46] <StevenK> wgrant: You mean, the publisher has?
[04:46] <wgrant> StevenK: Indeed.
[04:47] <lifeless> StevenK: that pastebin may be related yes.
[04:47] <lifeless> StevenK: however that looks like a racey test to me
[04:48]  * StevenK grumbles
[04:50] <stub> eh?
[04:50] <lifeless> stub: I suspect a fat index or something - 970 timeouts on the bugstats portlet
[04:51] <stub> Got an OOPS handy?
[04:51] <wgrant> So, I'd like to get http://paste.ubuntu.com/506212/ run on prod to see how widespread the carnage is.
[04:51] <lifeless> lpmain_staging=> SELECT COUNT(*) FROM Bug, BugTask WHERE BugTask.bug = Bug.id AND BugTask.id IN ( SELECT BugTask.id ... taking 15 seconds
[04:51] <lifeless> stub: theres tonnes in the oops report, but e.g. https://lp-oops.canonical.com/oops.py/?oopsid=1738C1035
[04:53] <StevenK> lifeless: Count(*) is expensive as hell anyway?
[04:53] <lifeless> StevenK: yes but
[04:53] <lifeless> StevenK: this is normally a subsecond query.
[04:53] <lifeless> StevenK: count(*) cost is a nuanced topic, its not guaranteed cheap is the main thing to remember.
[04:54] <StevenK> wgrant: Is that the same SQL lifeless ran on staging?
[04:54] <wgrant> StevenK: Except that it tells me how many are in each archive, yes.
[04:55] <StevenK> Does it give the archive name, or just the id?
[04:56] <wgrant> Just the id.
[04:57] <StevenK> wgrant: I wonder if it's worth twiddling the SQL for the archive name?
[04:57] <wgrant> StevenK: I'm not allowed to possess that.
[04:57] <StevenK> Oh, right
[04:58] <wgrant> The only archive that I really care about the identity of is archive 1, and I know which that is.
[05:02]  * StevenK prods lifeless towards the SQL wgrant is talking about for a +1
[05:03] <lifeless> +1
[05:03] <lifeless> you'll need to put it on LPS etc etc
[05:03] <wgrant> LPS for a SELECT!?
[05:03] <lifeless> oh, ebrain
[05:03] <spm> 506212?
[05:03] <lifeless> StevenK: you don't need cross-check approval for readonly queryies
[05:03] <wgrant> That.
[05:04] <lifeless> unless the losa in question looks at you funny.
[05:04] <StevenK> Ah
[05:04] <spm> vs the losa in question looking funny. which is a different problem.
[05:04] <StevenK> spm: Pls fix and make wgrant happy?
[05:04] <spm> StevenK: see that's the problem. the 2nd part of that sentence. I'm not sure I wish to comply.
[05:05] <spm> esp when the alt is far more entertaining for me!
[05:05] <StevenK> s/happy/less angsty/ ?
[05:05] <spm> it amounts to the same thing from my perspective.
[05:05] <wgrant> StevenK: Hey, this is my most monumental screwup ever :P
[05:06] <spm> ^^ young and experienced. Bigger and more spectacular screwups will come....
[05:06] <spm> *in*experienced.
[05:06] <spm> gah. troll typo fail :-)
[05:07] <StevenK> Bwahaha
[05:07] <wgrant> Heh.
[05:07] <spm> wgrant: http://paste.ubuntu.com/506216/
[05:07] <wgrant> Oh thank god.
[05:08] <spm> yes. you should thank me.
[05:08] <wgrant> Hah.
[05:08] <StevenK> 3781 in id 1?
[05:08] <wgrant> Yep.
[05:08] <wgrant> That's a really good thing.
[05:08]  * StevenK wonders how to get the id of the Launchpad PPA
[05:08] <wgrant> Because every broken publication in the primary archive is trivially revertable with a single query.
[05:09] <wgrant> Since there are so few archives, I might just join against archive, and get owner.name, archive.name and archive.private.
[05:11] <StevenK> wgrant: You were afraid it was going to be every archive?
[05:11] <wgrant> StevenK: More than 37.
[05:12] <StevenK> Why 37? That was the number on staging?
[05:12] <stub> lifeless: That query is performing very poorly under PG 8.4
[05:13] <wgrant> No, I just expected there'd be more than we got.
[05:14] <wgrant> spm: http://paste.ubuntu.com/506220/
[05:15] <wgrant> Hopefully there'll be no private archives. Or at least only private archives in public teams.
[05:15] <stub> bug at over 7 seconds under 8.3, the query sucks already.
[05:16] <lifeless> stub: it takes 780ms on staging
[05:16] <lifeless> stub: isn't staging 8.4 ?
[05:16] <stub> Yes. Hmm...
[05:17] <stub> The production db is all freshly packed - it is only a few days old.
[05:17] <stub> production 8.4 one that is (which I think is where all the timeouts are coming from - the OOPS is talking to the slave, and we have only one slave atm)
[05:18] <stub> But 272 seconds is a little extreme...
[05:18] <lifeless> rotfl
[05:19] <StevenK> That's only nearly 5 minutes, what's the problem? :-)
[05:21] <stub> Comments in the SQL like "                -- We create this rather bizarre looking structure" don't inspire confidence ;)
[05:22] <lifeless> yeah, indeed.
[05:22] <lifeless> stub: so, staging is 8.4 and fast, prod slave is 8.4 and slow ?
[05:22] <stub> yup. staging data is from about 6-7 days ago though.
[05:23] <wgrant> spm: http://paste.ubuntu.com/506220/
[05:23] <wgrant> Maybe my connection will survive this time.
[05:24] <lifeless> so one possibility is a something thrown out by new data?
[05:24] <StevenK> wgrant: Wishful thinker
[05:24] <StevenK> Hahaha
[05:24] <lifeless> it seems improbably to me, given the depth of history, it would need a huge seachange to alter the right query structure
[05:24] <StevenK> spm: Quick! Run the query while he isn't looking.
[05:24] <lifeless> stub: any clues from analyze?
[05:24] <stub> yes. The slow bit is an expensive nested loop the planner thought would get a single row but actually got over 5000, so 5000 times slower than expected.
[05:24] <spm> I've already done it. just trying to confirm the results for him :-D
[05:25] <stub> lifeless: http://paste.ubuntu.com/506228/
[05:26]  * stub runs an analyze on hackberry for a laugh
[05:28] <lifeless> stub: compare the plan on staging
[05:29] <lifeless>          ->  Nested Loop Anti Join  (cost=19392.56..26967.75 rows=1 width=4) (actual time=766.504..860.778 rows=5576 loops=1)
[05:29] <lifeless> if thats what you were saying is the issue, staging has it too
[05:34] <lifeless> stub: this seems to be a key, slow, but
[05:34] <lifeless> (bit(
[05:34] <lifeless> Bitmap Heap Scan on bugtask  (cost=295.98..20874.68 rows=15471 width=24) (actual time=9.812..139.968 rows=19011 loops=1)
[05:34] <lifeless>                                                    Recheck Cond: (status = 15)
[05:34] <lifeless>                                                    Filter: ((assignee IS NULL) AND (milestone IS NULL))
[05:34] <lifeless>                                                    ->  Bitmap Index Scan on bugtask__status__idx  (cost=0.00..292.11 rows=23310 width=0) (actual time=5.382..5.382 rows=24160 loops=1)
[05:34] <lifeless>                                                          Index Cond: (status = 15)
[05:34] <mwhudson> query plans and irc, a match made in heaven
[05:44]  * StevenK grumbles at the continued hiding of launchpad-dependencies in the PPA
[05:44] <stub> so the estimates are in the same ballpark, which means the planner meant to choose this bogus plan
[05:45] <stub> full analyze hasn't helped anyway (just in case autovacuum stuffed up or the statistics were screwed after the restore)
[05:45] <stub> Of course, if I was a query planner I'd take one look at that query and run away screaming
[05:45] <lifeless> stub: I need to pop out; I'll leave this with you
[05:45] <stub> gee, thanks ;)
[05:46] <lifeless> if you need a hand I'll be back after dinner ;)
[05:46] <lifeless> I do wonder why its choosing this plan
[05:47] <lifeless> still, 800ms is slow anyway, perhaps the best thing is just to:
[05:47] <lifeless>  - stop filtering private bugs from the count
[05:47] <stub> The nested loop I pointed out earlier - it wasn't expecting to execute that sub query so many times.
[05:47] <lifeless>  - stop trying to match up all the rules
[05:48] <stub> Yes, overly precise  counts have bitten us before.
[05:48] <lifeless>  - and just do a group by/count
[05:48] <wgrant> StevenK: You can revive it if you want.
[05:49] <wgrant> Delete it and copy it back.
[05:49] <StevenK> wgrant: Can't we just fix it?
[05:49] <wgrant> StevenK: Hopefully.
[05:50] <wgrant> Need to get the fix cowboyed, check if any of them have been deathrowed yet, and then hopefully just mass-revert the status.
[05:51] <wgrant> *Hopefully*.
[06:25] <StevenK> lifeless: I think EdwinGrubbs' post on the dev list points out the problem -- is that your doing too?
[07:54] <lifeless> back
[07:54] <StevenK> lifeless: https://code.edge.launchpad.net/~stevenk/launchpad/librarian-teardown-failure/+merge/37561
[07:54] <StevenK> (Per the discussion on the -dev list)
[07:55] <lifeless> no, thats wrong.
[07:55]  * StevenK goes to get a drink, instead of snapping
[07:55] <lifeless> I'm replying to the list now.
[08:00] <lifeless> StevenK: I'm sorry that its wrong - I know infrastructure problems are frustrating. When I say wrong, I don't mean 'unstylistic', I mean 'it will cause other insidious test failures.'
[08:04] <StevenK> lifeless: Sorry, I'm only frustrated since I've seen errors like this since Saturday, but had no time to look
[08:04] <lifeless> StevenK: can't have been since saturday, the code landed monday night.
[08:05] <lifeless> revno: 11667 [merge]
[08:05] <lifeless> committer: Launchpad Patch Queue Manager <launchpad@pqm.canonical.com>
[08:05] <lifeless> branch nick: launchpad
[08:05] <lifeless> timestamp: Mon 2010-10-04 07:20:04 +0100
[08:05] <lifeless> message:
[08:05] <lifeless>   [r=mwhudson][ui=none][no-qa] Start consolidation and rationalisation of Librarian test helper code.
[08:05] <lifeless> whatever is causing you grief since saturday is different.
[08:07] <henninge> Hi wgrant! ;)
[08:08] <StevenK> General warnings.
[08:08] <StevenK> /usr/lib/python2.6/atexit.py:24: DeprecationWarning: Attempt to tearDown inactive fixture.
[08:08] <StevenK> lifeless: With your patch ^
[08:09] <lifeless> StevenK: thats fine
[08:09] <lifeless> belt and braces
[08:09] <lifeless> we'll get rid of that when we get rid of the atexit
[08:09] <lifeless> which is another iteration
[08:12] <bac> lifeless: i got the following errors with your patch: http://pastebin.ubuntu.com/506298/
[08:12] <lifeless> bac: ok, I thought it might be incomplete.
[08:12] <lifeless> thanks
[08:20] <lifeless> bac: can you add a print cls.__bases__ into my patch and show me the result ?
[08:35] <bac> (<class 'canonical.testing.layers.BaseLayer'>,)
[08:35] <lifeless> oh
[08:35] <lifeless> bac: can you do that in LaunchpadScriptLayer.tearDown ?
[08:35] <bac> (<class 'canonical.testing.layers.BaseLayer'>,)
[08:36] <lifeless> really?
[08:36] <bac> lifeless: yeah,it was called twice
[08:36] <lifeless> oh right
[08:36] <bac> lifeless: the prints don't show up, so i put in a breakpoint
[08:36] <lifeless> I thought you were answering the script case
[08:37] <lifeless> bin/test -vvt old-testing.txt -t spec-mail-exploder.txt
[08:37] <lifeless> with
[08:38] <lifeless> --- lib/canonical/testing/layers.py     2010-10-04 06:20:04 +0000
[08:38] <lifeless> +++ lib/canonical/testing/layers.py     2010-10-05 07:36:47 +0000
[08:38] <lifeless> @@ -1338,6 +1338,7 @@
[08:38] <lifeless>      @classmethod
[08:38] <lifeless>      @profiled
[08:38] <lifeless>      def tearDown(cls):
[08:38] <lifeless> +        print cls.__bases__
[08:39] <bac> lifeless: i don't mind helping, but do you not have a dev env setup?
[08:39] <lifeless> bac: I don't experience the problem.
[08:40] <bac> really?  wow!
[08:40] <lifeless> as I said on list
[08:40] <lifeless> it passed ec2test
[08:40] <bac> (<class 'canonical.testing.layers.ZopelessLayer'>, <class 'canonical.testing.layers.LaunchpadLayer'>)
[08:41] <bac> it died on ec2 for me twice
[08:42] <lifeless> so, its not __bases__, that appears to be constant and fine.
[08:53] <lifeless> ...
[08:54] <lifeless> bac: bah, isp failure
[08:56] <lifeless> EdwinGrubbs: around ?
[08:58] <bac> lifeless: it is 3am for EdwinGrubbs
[08:58] <lifeless> ah
[08:59] <lifeless> for some reason I thought he was eu
[08:59] <lifeless> ohhh
[08:59] <lifeless> I wonder
[09:00] <lifeless> I'm trying to figure out hth this got into the system
[09:10] <wgrant> henninge: Hi.
[09:10] <henninge> wgrant: Hi, otp now ;)
[09:12] <wgrant> bigjools: http://paste.ubuntu.com/506231/ is the list of casualties and their archives (from prod a few hours ago)
[09:12] <wgrant> So it's mostly the primary archive, which is handy.
[09:12] <bigjools> wgrant: context?
[09:13] <wgrant> bigjools: the _getOtherPublications bug.
[09:13] <bigjools> ok
[09:13] <bigjools> I think we'll run the fix on staging first for this one
[09:14] <wgrant> I'd say so.
[09:30] <bigjools> wgrant: so, the new query looks the Thing.
[09:30] <wgrant> bigjools: It also returns the same result as my original one.
[09:30] <bigjools> always a bonus
[09:30] <bigjools> I guess it's trawling quite a few rows
[09:31] <wgrant> Just a few.
[09:31] <bigjools> the question is, do we want to fix PPAs too
[09:31] <wgrant> We should do something. Even if it's marking them Deleted instead.
[09:32] <bigjools> hmmm
[09:32] <bigjools> so my questions are, what happens if we do nothing, and what happens if we run this fix on them?
[09:33] <wgrant> If we do nothing, we end up with confusing old data.
[09:34] <wgrant> A few PPAs end up with some missing packages.
[09:34] <wgrant> But most of those are probably obsolete anyway.
[09:35] <wgrant> If they haven't been deathrowed already, we can just set them back to Published and everything will work.
[09:35] <wgrant> If they have been deathrowed, we should probably just mark them Deleted, because it's messy and it's probably that nobody will notice.
[09:43] <wgrant> However, we should get the fix cowboyed or CP'd and make the primary archive consistent first, I suspect, given what time it is.
[09:43] <wgrant> The whole release thing on Sunday.
[09:47] <allenap> bigjools, wgrant: Is what you're talking about related to the broken ppa:launchpad/ppa?
[09:49] <wgrant> allenap: Yes.
[09:50] <allenap> wgrant: Okay, cool. Do you know of any PPA mirrors I can use that are out of date, and thus not broken? I'm going to do a lot of twiddling thumbs today otherwise :)
[09:51] <wgrant> allenap: You could always grab launchpad-dependencies manually.'
[09:51]  * wgrant finds the link.
[09:51] <allenap> wgrant: Ah, it's in the PPA, just not in the manifest or whatever it's called?
[09:52] <bigjools> ppa:launchpad/ppa got broken too?
[09:52] <jtv> henninge, you'll want to know about this: a conflict has crept into your convert-imports branch.
[09:52] <jtv> henninge: lib/lp/translations/stories/translations/30-rosetta-pofile-translation-gettext-error.txt
[09:53] <wgrant> bigjools: Lucid's launchpad-dependencies were vaporised a couple of days back, yes.
[09:53] <bigjools> :/
[09:53] <mrevell> Hello
[09:53] <wgrant> bigjools: It's the only report of breakage, interesting enough.
[09:53] <wgrant> allenap: https://edge.launchpad.net/~launchpad/+archive/ppa/+sourcepub/1263354/+listing-archive-extra has the binaries you need.
[09:53] <bigjools> I've just started the query on staging to see how many rows there are when restricting to archive=1
[09:54] <allenap> wgrant: Thanks.
[09:54] <wgrant> bigjools: http://paste.ubuntu.com/506220/ was the last query I had run on production.
[09:54] <wgrant> Gives the count for each archive.
[09:54] <bigjools> yeah I have tjat
[09:56] <bigjools> wgrant: would you mind doing me a favor and making a query to fix the PPA publications while I do this?  I think we can filter on dateremoved
[09:57] <wgrant> bigjools: That was my thinking too.
[09:57] <bigjools> great minds ...
[09:57] <wgrant> Anything with dateremoved IS NOT NULL should be safe to just flip back.
[09:57] <wgrant> Which should cover all of the primary archive cases too, hopefully.
[09:57] <bigjools> ah very good point
[09:57] <bigjools> nm then
[09:57] <bigjools> I'll pop that in
[09:58] <henninge> jtv: thanks
[09:58] <wgrant> Just set the status, and unset datesuperseded, datemadepending and scheduleddeletiondate
[09:58] <wgrant> I think that should do it.
[09:59] <wgrant> Although the last two aren't relevant for the primary archive.
[09:59] <wgrant> If anything has those set we have other bugs.
[09:59] <henninge> wgrant: Did you see that test failure?
[09:59] <bigjools> and supersededby
[09:59] <wgrant> bigjools: erk, good point.
[09:59] <wgrant> henninge: Yes. lifeless ran it again, and it failed spuriously another way.
[09:59] <bigjools> :)
[09:59] <wgrant> Along with a few other branches.
[09:59] <wgrant> So there's something wrong with devel.
[10:01] <henninge> who ones merge proposals code?
[10:01] <henninge> s/ones/owns/
[10:01] <henninge> s/who/who in the code team/ ;)
[10:04] <lifeless> wgrant: should be fixed soon, branch is in pqm atm
[10:04] <wgrant> lifeless: Ah, great.
[10:04] <jtv> danilos, henninge: we've long wanted to use the permissions system for translations, but I find myself really not wanting to do that now.  What would permissions be _on_?   It seems weird to invent a DummyPOFile just to check permissions on it, for instance.
[10:05] <danilos> jtv, what do you mean with 'now'? do not want to use "full" zope machinery with this particular branch?
[10:06] <jtv> danilos: I mean "now that we're sharing translations so widely."
[10:06] <wgrant> bigjools: Should we run a query on prod to see how many have already been removed?
[10:06] <bigjools> doing it now
[10:07] <wgrant> With the per-archive counts?
[10:07] <bigjools> quite a lot it seems, I get a count of 842 in the query now
[10:07] <bigjools> after adding "bpph.dateremoved IS NOT NULL"
[10:07] <wgrant> On staging?
[10:07] <bigjools> yes
[10:08] <jtv> danilos: if it were just "are you one of the owners of this product," for instance, I'd have no problems.  But if we go pofile→potemplate→productseries→product→project→translationgroup→translator, that's a lot for a permissions check.
[10:08] <wgrant> Are any of those in the primary archive?
[10:08] <bigjools> one sec
[10:08] <danilos> jtv, well, sharing aspects of it will be relatively hard to map in the zope permissions system, but ideally, we'd at least make it a simple check: "can-do-something-here" and "can-do-something-on-the-other-side"
[10:08] <wgrant> The publications I checked hadn't had removal scheduled, so I doubt it.
[10:08] <danilos> jtv, ideally, we'd just check permissions on the pillar level (product/distribution), because that's where we get them from
[10:09] <danilos> except for pofile, of course
[10:09] <jtv> danilos: sure, that part's fine for me and may even hide a bit of the "if productseries" ugliness
[10:09] <jtv> danilos: that's the other thing—I really, _really_ don't want to give edit rights to pofile owners.
[10:10] <danilos> jtv, I am sure you can come up with a reasonable design, and you might be right that permissions system is not the right solution
[10:10] <danilos> jtv, right, we want maintainers to have edit rights on them, but other than that, just translators for appropriate language
[10:11] <jtv> danilos: I appreciate the trust.  :)  I think POFile.owner is a bit of an historical mistake; it's really "creator" except we always set it to rosetta-admins if the creator doesn't have edit rights already.
[10:11] <danilos> jtv, fwiw, do note that you will see tests breakage if pofile.owner can't edit a pofile (I am sure that in all our laziness we used that often :)
[10:11] <allenap> wgrant: Thanks for that link; my bacon has been saved.
[10:11] <wgrant> allenap: Yeah, uh, sorry about that.
[10:11] <danilos> jtv, oh, pofile.owner is bordering on the useless, I'd say
[10:11] <jtv> danilos: there's a good point… another reason to clean up, probably.
[10:12] <allenap> wgrant: Ah, are you the culprit? :)
[10:12] <jtv> danilos: if we stop giving it any privileges, we can also set it to the actual creator rather than "set to creator _if_ it doesn't conflict with current permissions."
[10:12] <wgrant> allenap: Yes :/
[10:12] <danilos> jtv, then it'd be nice to rename it as well
[10:12] <jtv> danilos: it may also avoid some of those cases where someone who's not in the translation team can continue to submit bad translations.
[10:12] <allenap> wgrant: Hehe, oops.
[10:12] <jtv> danilos: yes, I'd like that too.
[10:12] <wgrant> allenap: Rather.
[10:12] <danilos> jtv, true, true
[10:13] <danilos> jtv, so, basically, you want to drop "owner" field and create a different "created_by" field
[10:13] <danilos> jtv, I agree that'd be nice, but this is a cleanup job for later :) for now, you can simply ignore the owner for permissions
[10:13] <jtv> danilos: that's what I had in mind, yes.
[10:14] <danilos> jtv, cool, sounds good
[10:14] <jtv> The main thing right now is not to give special rights to pofile.owner, in which case the only things that matter are the person, the language, and the pillar.
[10:14] <jtv> I was thinking of making this a method in ITranslationsPerson, since we have so many functions about this spread out.
[10:23] <lifeless> ok, devel should be fixed
[10:25] <wgrant> lifeless: Could you fire of that branch again, or shall I convince someone else?
[10:25] <lifeless> someone else per favour
[10:25] <jml> hello
[10:29] <bigjools> hello
[10:31] <wgrant> henninge: Could you please ec2 that branch again?
[10:31] <wgrant> bigjools: Any progress?
[10:31] <bigjools> query still running
[10:31] <wgrant> Er.
[10:31] <henninge> wgrant: just test it or try to land it?
[10:31] <wgrant> Doesn't it only take three minutes?
[10:31] <wgrant> henninge: The latter.
[10:32] <henninge> wgrant: ok
[10:33] <bigjools> wgrant: probably on production
[10:33] <wgrant> bigjools: This was on staging.
[10:33] <bigjools> hmm
[10:33] <wgrant> Although it didn't have the archive/person join, that really shouldn't be that bad.
[10:33] <stub> So 250k of our 330k branches are owned by 'ubuntu-branches', which is rather lopsided and will certainly be triggering timeouts in some areas.
[10:33]  * bigjools kills it
[10:46] <wgrant> Who is buildbot angry with?
[10:49] <bigjools> wgrant: http://pastebin.ubuntu.com/506369/
[10:50] <lifeless> stub: any luck with the bug portlet stuff?
[10:50] <bigjools> wgrant: which means 1100 or so packages are lost in Ubuntu
[10:50] <wgrant> bigjools: Uh, is that dateremoved IS NOT NULL?
[10:50] <bigjools> yes
[10:50] <bigjools> wgrant: sorry
[10:50] <bigjools> :/
[10:51] <stub> lifeless: I'd say 1) work out what the query is trying to do 2) rewrite it.
[10:51] <lifeless> 1) might be hard :P
[10:51] <bigjools> wgrant: I meant to say, that's bpph.dateremoved IS NULL
[10:51] <wgrant> bigjools: Is that prod or staging?
[10:52] <bigjools> wgrant: staging
[10:52] <wgrant> bigjools: The 3700 was from prod.
[10:52] <bigjools> ok
[10:53] <bigjools> I need to land your fix on prod
[10:53] <wgrant> What does http://paste.ubuntu.com/506220/ say on staging? I suspect that will show that we haven't lost anything from the primary archive.
[10:53] <wgrant> Alternatively, what does your dateremoved IS NULL query say on prod?
[10:54] <wgrant> But yes, germanium and cocoplum want that patch.
[10:54] <bigjools> argh
[10:54] <stub> lifeless: Indeed. btw. the query I'm testing is slow on staging too, although better at a little under 30s. I'd suggest it is working at all under PG 8.3 purely by accident (if you consider 7 seconds working)
[10:54] <bigjools> I cna't remember if that query was with or without the NOT
[10:55] <lifeless> stub: thats odd; the one I copied from the OOPS I pasted takes 800ms on staging.
[10:55] <wgrant> bigjools: I'm fairly sure it must have been dateremoved IS NULL.
[10:55] <lifeless> stub: perhaps I'm connected to 8.3 on staging?
[10:55] <stub> There is no 8.3 on staging
[10:56] <stub> http://paste.ubuntu.com/506383/ is what I was looking at
[10:57] <lifeless> http://pastebin.com/w3h72qvC
[10:58] <bigjools> wgrant: right, nothing shows for NOT NULL in the main archive
[10:59] <wgrant> bigjools: So I'm not completely insane.
[10:59] <wgrant> This is good.
[10:59] <bigjools> wgrant: just slightly
[10:59] <stub> lifeless: I can confirm your query is fast on staging, fast on production 8.3, and slow on production 8.4.
[10:59] <lifeless> stub: cool
[11:00] <lifeless> stub: bizarre, but cool
[11:00] <wgrant> bigjools: How about the rest of the archives?
[11:00] <stub> lifeless: maybe data, or maybe less ram causing different query plans
[11:00] <bigjools> wgrant: http://pastebin.ubuntu.com/506387/
[11:01] <wgrant> bigjools: That's staging dateremoved IS NOT NULL?
[11:01] <bigjools> wgrant: yes
[11:01] <wgrant> OK, so we can take care of most of them trivially.
[11:03] <bigjools> wgrant: can you help me QA your fix on dogfood
[11:04] <wgrant> Once we've fixed the dateremoved IS NULL, I'll get a list of the remaining pubs and work out what to do with them.
[11:04] <wgrant> bigjools: Sure.
[11:04] <wgrant> Let's see how...
[11:04] <bigjools> wgrant: I'm updating its code, we need a test scenario
[11:07] <wgrant> bigjools: Easy enough. Just upload a new launchpad-dependencies to maverick in ppa:launchpad, run the publisher, and confirm that the old version is superseded in maverick but still alive in lucid.
[11:17] <wgrant> bigjools: Ah, I see that dogfood's PPA doesn't have a maverick launchpad-dependencies yet.
[11:18] <bigjools> yeah
[11:19] <bigjools> easily fixed
[11:28] <bigjools> grar, I need a no-sign mode for publishing PPAs
[11:29] <wgrant> Just unset the signing key, I suppose.
[11:29] <bigjools> still a pita
[11:29] <wgrant> How do you normally do it?
[11:29] <bigjools> either than or copy some .gpg files around
[11:30] <bigjools> that*
[11:32] <bigjools> I need a single ppa mode too
[11:32] <wgrant> 'UPDATE archive SET publish=false' FTW.
[11:32] <bigjools> heh
[11:48] <wgrant> bigjools: Er, why is the maverick publication Published but without a datepublished?
[11:49] <wgrant> Did you manually set that?
[11:49] <wgrant> Or is something even more broken?
[11:52] <bigjools> I've been hacking it
[11:53] <bigjools> looks like it worked ok
[11:54] <StevenK> bigjools, wgrant: Ah, is this to fix the no launchpad-dependencies in lucid problem?
[11:54] <wgrant> StevenK: Yes.
[11:54] <bigjools> -ish
[11:54] <wgrant> Right.
[11:56] <lifeless> mrevell: is there any reason we don't show the revno and 'get the code' link on launchpad.net ?
[11:56] <lifeless> mrevell: (compare the footer on  launchpad.net and edge.launchpad.net)
[11:56] <wgrant> production-stable isn't public.
[11:56] <lifeless> wgrant: prod stable isn't referenced.
[11:57] <wgrant> lifeless: It should be by prod...
[11:57] <lifeless> wgrant: and its going anyhow.
[11:57] <lifeless> wgrant: base-layout-macros.pt, or look at the two pages I referenced.
[11:57] <wgrant> launchpad.net's revno is on production-stable, which mortals cannot see.
[11:57] <lifeless> wgrant: imagine an epic shrug from me.
[11:57] <wgrant> Huh?
[11:57] <bigjools> lifeless: wow you're on the ball with my CP
[11:57] <bigjools> thanks
[11:58] <lifeless> bigjools: de nada
[11:58] <lifeless> wgrant: I'm making changes to match up with edge going, I don't care about the prod-stable stuff; I care about the UI
[11:58] <wgrant> lifeless: How can it work if production-stable isn't public? Unless you link to the completely wrong code...
[12:00] <lifeless> wgrant: we're deleting production-stable
[12:00] <bigjools> grrr lp-land not playing ball on that branch
[12:00] <wgrant> lifeless: Well, sure, once that's done.
[12:00] <mrevell> lifeless: Before it was the revno, it was also the version number. I think it was on edge, and staging, to help people see that edge was running different code to production and also to help with reporting of bugs. I don't see any reason to keep "Get the code" off production. The revno maybe feels to me like something you wouldn't see on a production web app but I don't have a strong opinion on it.
[12:00] <lifeless> wgrant: I can tolerate some imperfection
[12:01] <mrevell> lifeless: tl;dr Old reasons that probably don't apply now.
[12:01] <lifeless> mrevell: thanks
[12:06] <deryck> Morning, all.
[12:08] <wgrant> bigjools: So the CP is happening?
[12:08] <bigjools> wgrant: OTP
[12:08] <wgrant> k
[12:12] <lifeless> wow, isn't ohloh the hot potato
[12:13] <wgrant> Because it keeps failing to import LP?
[12:15] <wgrant> Oh, I see.
[12:15] <wgrant> Indeed.
[12:16] <wgrant> They can't seem to format their emails properly.
[12:22] <lifeless> mrevell: so, my blog post
[12:23] <lifeless> mrevell: could you hit 'go' on it before you EOD, or reply to me ?
[12:23] <lifeless> gnight all
[13:07] <matsubara> lifeless, thanks for landing that. :-)
[13:36] <wgrant> bigjools: I suppose we can do little more tonight, since the CP will not happen for ages?
[13:47] <allenap> gmb: There was a question directed at you in bug 605783, but I think it's something that deryck should take a look at.
[13:47] <_mup_> Bug #605783: SourceForge bugwatch updates are broken <bugwatch> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/605783>
[13:47] <leonardr> dumb zope browser/mechanize question: how can i iterate over all the buttons in a form?
[13:49] <leonardr> benji, maybe you know
 dumb zope browser/mechanize question: how can i iterate over all the buttons in a form?
[13:49] <leonardr> _get_all_controls is really particular about only letting me get _one_ control
[13:50] <leonardr> aha! .mech_form.controls
[13:51] <benji> leonardr: that'll work (but is undocumented/unsupported); you can also use beautifulsoup
[13:51] <leonardr> what is this "beautifulsoup"?
[13:52] <deryck> allenap, I'll comment there.  I saw it but was trying to figure out if we could get this scheduled.
[13:53] <leonardr> benji: more seriously, is there a shortcut for making a soup of the current browser page?
[13:53] <leonardr> i see some examples in pagetests but they do it from scratch
[13:53] <allenap> deryck: Yeah, that's what I meant really.
[13:54] <deryck> allenap, understood.  I feel bad because we really should get this fixed.  But it can't happen anytime soon.
[13:54] <benji> leonardr: heh; BeautifulSoup(browser.contents)
[13:55] <leonardr> benji: ah! i was thinking of helper *functions* like find_tags_by_class, which make a BS object and do something else
[13:57] <deryck> So nice to not see [object Object] when I comment on bugs now.
[14:00] <leonardr> benji: actually, it looks like the right thing to do is to call find_tag_by_id(browser.contents, 'maincontent')
[14:00] <leonardr> that gives you a bs tag
[14:00] <leonardr> i don't think we create a bs object unless we really need the whole page
[14:00] <bigjools> wgrant: nope, we need to wait for it to land
[14:01] <bigjools> wgrant: then we can roll it out and do the SQL to fix everything
[14:01] <wgrant> Sounds good.
[14:03] <bigjools> where "everything" is followed by a sarcasterisk
[14:37] <jml> bigjools: could you tell me why this query returns 0 rows?
[14:37] <jml> http://paste.ubuntu.com/506504/
[14:37] <jml> it used to return lots
[14:52] <bigjools> jml: what are you trying to do?
[14:53] <jml> https://lpstats.canonical.com/graphs/UddSourcePackagesWithoutBranches/
[14:55] <bigjools> jml: DistroSeries.releasestatus = 2 ?
[14:55] <jml>         # DistroSeries.releasestatus == 2 => under active development
[14:55] <bigjools> jml: it's not any more
[14:55] <bigjools> it's frozen
[14:56] <jml> bigjools: that'll be it then.
[14:57] <jml> bigjools: thanks.
[14:58] <bigjools> jml: np!
[14:58] <bigjools> glad to be helping you for a change :)
[15:01] <jml> uhh :(
[15:01] <jml> SeriesStatus.DEVELOPMENT == 2 :(
[15:02] <StevenK> jml: That isn't what bigjools meant.
[15:02] <StevenK> jml: Not that 2 isn't Development; that Maverick itself is Frozen. It won't thaw until release.
[15:02] <bigjools> jml: maverick is in "Pre-release Freeze"
[15:02] <bigjools> not development
[15:03] <jml> bigjools: but I'm not searching for maverick in that query.
[15:03] <bigjools> jml: there are no other series in development
[15:03] <bigjools> it would have been matching only maverick
[15:03] <jml> ahh ok. now I get it.
[15:03] <jml> I guess I need to make it say "releasestatus IN (2, 3)"
[15:04] <bigjools> when natty is opened it'll be experimental for a bit too
[15:04] <leonardr> jml, can i get your buy-in on https://dev.launchpad.net/LEP/DesktopWideLaunchpadIntegration? i already have buy-in from kees, lifeless, and other luminaries
[15:04] <jml> leonardr: almost certainly
[15:04] <jml> leonardr: I feel obliged to read it before I approve it though.
[15:04] <leonardr> please do
[15:04] <jml> leonardr: but I've been following the ML discussion so I reckon it'll be smooth
[15:05] <allenap> deryck: What do we do with feature suggestions normally? https://answers.edge.launchpad.net/malone/+question/127685
[15:05] <allenap> Convert to a wishlist bug?
[15:06] <jml> allenap: orbital lasers.
[15:06] <allenap> jml: Lol. Getting a GPS fix now.
[15:06] <deryck> allenap, yeah, but I think this "have pretty graphs" bug already exists somewhere.
[15:08] <allenap> deryck: I can't find it, but I can reply saying that, yes, we want it too, and perhaps paste kfogel's contributor bait paragraph too?
[15:10] <allenap> If I can find *that*.
[15:56] <jml> can I persuade someone to write a script that shows all of the in-progress work on Launchpad at a branch/revision/bug level, broken down by stage (e.g. needs-reviews, needs-qa, being-tested, awaiting-deployment etc)
[15:57] <jml> ./utilities/branch-flow is something of a start, but isn't really that great.
[16:02] <jml> leonardr: contrariwise, could you please look at https://dev.launchpad.net/LEP/ActivatingDevelopmentFromDesktop
[16:03] <leonardr> jml: there's a small chance that my lep obsoletes that one, but if not, there's not much overlap.
[16:03] <leonardr> ActivatingDevelopmentFromDesktop is currently the one remaining case where we authorize an app-specific token
[16:04] <leonardr> (obsoletes that one == obsoletes the part about time-limited authorization keys)
[16:04] <jml> leonardr: ahh ok.
[16:05] <jml> leonardr: I've just approved DesktopWideLaunchpadIntegration. Thanks for the clear write-up.
[16:05] <leonardr> i have not done exhaustive research, but it's possible that a time-limited authorization key will not really provide much additional security
[16:05] <leonardr> sure
[17:17] <mars> benji, did you see the mailing list thread about the LayerIsolationError?  Is that what you are experiencing?
[17:43] <danilos> jcsackett, hi (btw, I don't see you on #launchpad-reviews)
[17:43] <jcsackett> danilos: hi, no, i'm CHR today and got lost in that and now a testfix; completely forgot to join #launchpad-reviews.
[17:43] <jcsackett> i'll join that channel if you would prefer.
[17:43] <danilos> jcsackett, just one question about the branch you asked me to review? what is the goal behind it? just switching from official_rosetta to the usage enum?
[17:44] <danilos> jcsackett, nah, this is fine, just thought I'd mention it if you want to add it to your auto-join channel list :)
[17:44] <jcsackett> no, that goal has been met, this is dealing with consistency in configuration for usage_enums.
[17:44] <jcsackett> other services have a config option even when set to ServiceUsage.LAUNCHPAD; translations did not, as it has no action menu to grab the global action.
[17:45] <jcsackett> so, for consistency's sake, the branch adds one there (so you could, say, disable the enum for a product if it's enabled).
[17:45] <danilos> jcsackett, oh, so you mean it's about adding it to the translations.lp.net pages?
[17:45] <jcsackett> danilos: not entirely sure what you mean.
[17:46] <jcsackett> the branches sole goal was to add a configuration link for the usage enum to translations when translations is already enabled (via enum) on a product.
[17:46] <danilos> jcsackett, well, it was possible to set it on "registry" pages
[17:46] <jcsackett> ah, i see.
[17:46] <jcsackett> right, the translations front page; so translations.launchpad.net/<product>
[17:46] <danilos> jcsackett, right, so this is exactly the thing that I wanted to move to the global "configure translations" page :)
[17:47] <danilos> jcsackett, thanks for explaining the reasoning, I'll comment on the bug
[17:47] <danilos> jcsackett, we can get this landed, but it just makes stuff more confusing imo
[17:47] <danilos> jcsackett, also, if all the other apps are using action menus, we should probably do that for translations too
[17:48] <jcsackett> danilos: that's why i requested you review it; it's possible the bug it's filed against isn't really valid.
[17:48] <jcsackett> all other apps are dealing with collections and have the same basic interface (list of related items). translations is an exception to that, so it's possible that the configuration option belongs in +settings or something, as those other bugs you pointed out describe.
[17:51] <danilos> jcsackett, I am not sure I agree with that statement (translations pages deal with collections as well, and we quite specifically show a list of languages on the product frontpage); there are ways to get to a list of templates, or list of imports, so I think we are not that special case, but might just be out of date on the design side
[17:51] <danilos> jcsackett, and if we are, I want to fix that :)
[17:52] <danilos> jcsackett, also, why do we use the camel case capitalization for the title on "Configure Translations" pages? I thought the agreed norm was to not use it
[17:53] <danilos> salgado-lunch, hey, UI reviewer, what's the recommended capitalization for web page titles? :)
[17:57] <jcsackett> danilos: what part of this branch makes it more confusing? just the addition of yet another configuration option?
[18:12] <danilos> jcsackett, yeah (i.e. instead of fixing it all to be on the same page, we are spending effort to introduce the new page)
[18:15] <jcsackett> danilos: fair. it's a bit of a stopgap.
[18:15] <jcsackett> if you could write up a good reason we don't need this in favor of a better settings page on the MP, i'm fine to abandon the branch and mark the related bug as wontfix.
[18:16] <jcsackett> danilos: we just need an explanation for leaving it as is when we go to mark the bridging-the-gap feature work as done.
[18:16] <danilos> jcsackett, right, and as such, I don't have a big problem with the branch as-is
[18:16] <jcsackett> danilos: less of course fixing the issues with title &c?
[18:16] <danilos> jcsackett, well, it's ultimately your call: I will write up an explanation, but other than a minor issues, I am fine with it landing as well
[18:17] <danilos> jcsackett, so, I'll approve the branch as well
[18:17] <jcsackett> danilos: cool. sounds good. :-)
[18:17] <jcsackett> thanks, danilos.
[18:17] <jcsackett> danilos: FWIW I would love to see (and help with) a more unified translations settings page. :-)
[18:17] <jcsackett> (though the help with part may have to be mostly on my own time.)
[18:18] <danilos> jcsackett, heh, sure, we'll work on it pretty soon now as well: we want to streamline translations setup as our next step
[18:18] <jcsackett> danilos: awesome. :-)
[18:33] <sinzui> flacoste, meeting on mumble?
[18:43] <flacoste> sinzui: yes
[18:44] <salgado> danilos, according to https://dev.launchpad.net/UserInterfaceWording, it should be sentence case
[18:44] <danilos> salgado, right, thanks
[18:44] <danilos> jcsackett, ^ (link by salgado :)
[18:46] <jcsackett> danilos: dig; i'll make that change.
[19:28] <lifeless> moin
[19:28] <jelmer> lifeless!
[19:29] <lifeless> hi jelmer
[19:29] <deryck> morning, lifeless.
[19:29] <lifeless> hey deryck
[19:57]  * tyarusso sighs
[19:57] <lifeless> ?
[19:58] <tyarusso> Has *anyone* succeeded in setting up their own production instance of Launchpad + CIP?  I'm getting failures finding things from pip with CIP currently.
[19:58] <tyarusso> * anyone other than Canonical, of course
[20:01] <tyarusso> I wish Canonical offered hosted Launchpad instances for businesses, or at least a consulting service to set it up for you.
[20:03] <jpds> tyarusso: I would talk to bac.
[20:06] <tyarusso> jpds: do you know when s/he is normally around?
[20:10] <lifeless> jpds: bac doesn't do that anymore, mrevell does
[20:10] <lifeless> tyarusso: hi; we do run private content for businesses that want it, on the production LP.
[20:11] <lifeless> tyarusso: matthew.revell at canonical.com would be good to talk to about your needs.
[20:11] <sinzui> flacoste, PS 4198 pillar/person name collisions, 1509 of these are actually teams
[20:12] <flacoste> sinzui: you mean we have 4.2k project that have the same name than a team?
[20:12] <sinzui> 1509 have the same name as a team
[20:12] <tyarusso> lifeless: Well, that situation we would want is to have it under our domain name and branding, which I was previously told isn't possible currently with your stuff.  Still true?
[20:12] <sinzui> 2.5k are users with the same name
[20:13] <flacoste> ack
[20:13] <lifeless> tyarusso: thats true, launchpad itself isn't capable of being branded multiple ways in a single deployment.
[20:14] <tyarusso> lifeless: Do you think revell would be useful for helping us set up our own, or is that outside of his scope?
[20:14] <lifeless> I'd just ask on the launchpad-dev mailing list
[20:16] <tyarusso> k
[20:17] <tyarusso> It's being rather hard to convince myself to do this instead of 'apt-get install gforge', which is a shame, since LP is rather nice once it's up.
[20:22] <flacoste> deryck: did we deselect the automatic expiry before sending the notifications?
[20:23] <flacoste> tyarusso, lifeless: it's outside of his scope
[20:23] <flacoste> tyarusso: the only instance i know of a rebranded LP is quickbuild
[20:23] <deryck> flacoste, actually, no.  Send then deselect.  That was a bad choice in hindsight.
[20:23] <flacoste> deryck: it is!
[20:23] <flacoste> deryck: i just went to my project to enable it
[20:24] <flacoste> and saw it was already enabled
[20:24] <deryck> yeah, it's a bad choice.  not sure if we should do anything to correct it now.
[20:25] <flacoste> tyarusso: https://quickbuild.pearsoncomputing.net/
[20:25] <flacoste> deryck: i'd say send a second email once you deselect it for real
[20:25] <flacoste> deryck: because anybody who acted on your email right away will be screwed
[20:26] <flacoste> or at least very confused
[20:26] <deryck> flacoste, sure.  I can do that.
[20:26] <deryck> hate to spam, but it's probably the reasonable thing to do.
[20:29] <tyarusso> flacoste: hmm, interesting.  Who runs that?
[20:31] <flacoste> tyarusso: be aware thought that it's not a full deployment, there are stuff that is disabled
[20:31] <flacoste> tyarusso: i can't remember
[20:31] <flacoste> but he's the maintainer of the trinity project
[20:32] <flacoste> (continue to support packaging of KDE 3 series)
[20:35] <tyarusso> well, out of time for today.  Maybe better luck tomorrow...
[20:35] <flacoste> gary_poster: thanks for your branch on bug 650343, but the header name actually changed
[20:35] <_mup_> Bug #650343: Add X-Launchpad-Original-To to recipient lists <Launchpad Foundations:Triaged by gary> <https://launchpad.net/bugs/650343>
[20:35] <flacoste> gary_poster: it's now X-Launchpad-Original-To, (not X-Original-To)
[20:36] <gary_poster> flacoste: ah, misunderstood.  Not merged for other reasons.  Will make a change
[20:40] <bdmurray> sinzui: I'd like to edit the permissions for OfficialBugTagsManageView so that bug supervisors can also edit them.  Would I add a class for this to security.py?
[20:43] <sinzui> bdmurray, isn't that also security on the context object. I think the rules are in there, and the rules on the view just work
[20:43]  * sinzui looks
[20:46] <lifeless>  we can't use views for security though
[20:46] <sinzui> have I gone mad? I thought there was a bugtag interface and model
[20:47] <bdmurray> lp.bugs.interfaces.bugtarget.IOfficialBugTagTargetRestricted ?
[20:48] <sinzui> bdmurray, thanks so we do have an interface, now I will check the zcml
[20:53] <sinzui> bdmurray, there is nothing to edit
[20:54] <bdmurray> sinzui: it is just launchpad.Edit now right?  I want to extend this to bug supervisor.
[20:55] <sinzui> bdmurray, IOfficialBugTagTargetRestricted is only used to define security on the view and since there is no rule for IOfficialBugTagTargetRestricted, it falls back to target types lp.Edit (distro|product|dsp|dseries|pseries)
[20:55] <bdmurray> sinzui: yes, so I'm asking how to make this rule
[20:56] <sinzui> bdmurray define a security checker for IOfficialBugTagTargetRestricted that checks the admin, target.owner, target.bug_supervisor
[20:57] <bdmurray> sinzui: okay, that's what I'd thought and it what would the value of usedfor be?
[20:57] <sinzui> bdmurray, in the case of a project or any kind of series, I think checking target.driver is also correct. This addition ensure Release managers can tag their bugs
[20:58] <sinzui> bdmurray, usedfor = IOfficialBugTagTargetRestricted
[20:58] <bdmurray> sinzui: okay, thanks for the help
[21:16] <lifeless> flacoste: I intend to just Edit the wiki pages surrounding production changes to match RFWTAD - do you want any editorial oversight ?
[21:16] <lifeless> flacoste: or will you just look and tweak post-hox
[21:17] <flacoste> lifeless: please be my guest, i'll tweak post-hoc if needed
[21:18] <negativezero> hey guys, is is appropriate to ask about the launchpad-developer-dependencies package in here? #launchpad is awfully quiet
[21:20] <sinzui> negativezero, this is the correct place
[21:21] <negativezero> i'm trying to install launchpad locally, but apt can't seem to find the aforementioned package.  i've used both rocketfuel-setup and added the ppa's to my apt sources
[21:22] <sinzui> negativezero, :( rocketfuel-setup does add the archives to your sources list
[21:22] <sinzui> what version of Ubuntu do you have?
[21:22] <negativezero> 10.04
[21:22] <rockstar> sinzui, how do I handle database records that reference Person?
[21:24] <sinzui> negativezero, did you also update your apt-cache to see what is in those soruces
[21:24] <sinzui> rockstar, ?
[21:24] <rockstar> sinzui, I should have put quotes around "handle."
[21:25] <rockstar> sinzui, I get a nice "NotImplementedError: branchmergequeue.owner reference to person.id is in a UNIQUE index but has not been handled"
[21:25] <sinzui> rockstar, what are database records?
[21:25] <rockstar> sinzui, database patches.
[21:25]  * rockstar needs to pull his head out...
[21:27] <mwhudson> rockstar: is this in the person merge tests?
[21:27] <rockstar> mwhudson, yes.
[21:27] <mwhudson> you need to add code in the person merge code to decide what to do
[21:27] <rockstar> mwhudson, well, no, it's in all sorts of tests, but I assume it has to do with the person merge stuff.  That's why I asked sinzui in the vaguest way possible.
[21:28] <mwhudson> oh
[21:28] <rockstar> mwhudson, but I assume what you say is correct.
[21:28] <rockstar> mwhudson, where is the person merge code?
[21:28] <negativezero> sinzui: i ran an apt-get update. is there a command to update apt-cache specifically?
[21:29] <rockstar> negativezero, that's what apt-get update does.
[21:29] <sinzui> rockstar, I think I understand. in cases where this could happen, we often check that it can happen, then ask the user to either destroy the object to prevent a unique key violation, or we add rules that make the new items unique
[21:29] <rockstar> negativezero, I suspect that the PPAs are out of date with Lucid now, since we've all switched to maverick.
[21:30] <sinzui> negativezero, you did the right thing
[21:30] <rockstar> sinzui, can't we just change the order?
[21:30] <rockstar> s/order/owner...
[21:30] <negativezero> there's some launchpad-integration packages in my cache
[21:30] <rockstar> Dammit I should go back to bed and hope tomorrow gets better.
[21:31] <sinzui> rockstar, I saw an oops like this in translationqueueentries recently. I decided to to change the owner. The other option is to tell the user he must wait until the queue is cleared
[21:32] <sinzui> rockstar, in the translationqueue issue, we discussed there is a chance that permissions will be lost. I do not know what to do in the case of  branchmergequeue.owner, but I think you want to add a rule to change it to the new owner
[21:33] <rockstar> sinzui, okay, so where's the code that "handles" this kind of problem?
[21:33] <rockstar> (Basically, how do I fix these tests)
[21:34] <sinzui> rockstar, lp/registry/model/person.py look for the for "def _merge"
[21:34] <rockstar> sinzui, ah, okay.
[21:35] <sinzui> rockstar, you may want to look at lp/registry/browser/peoplemerge.py if you decide you need to tell the user to wait for the queue to empty.
[21:36] <rockstar> sinzui, this queue is like the pqm queue.  If you're lucky, it'll NEVER be empty.  :)
[21:36] <sinzui> rockstar, can I have more than one item in the queue?
[21:36] <rockstar> sinzui, yes, but they already have owners.
[21:36] <rockstar> (The items are branch merge proposals)
[21:37] <sinzui> excellent just look at the model you only need to add or update a rule to change their owners
[21:52] <rockstar> sinzui, it does seem a bit odd that I get this on a failure in a database patch branch.
[21:54] <sinzui> rockstar, I think salgado/stub is pretty clever I suspect they check that for everything a person links to has a rule in person merge
[21:56] <rockstar> sinzui, okay.  Thanks for your help.  I think that'll be the last of my failing tests.
[21:59] <lifeless> flacoste: ok, I think I'm done.
[22:03] <wgrant> Grararrara
[22:03] <rockstar> abentley, wallyworld, is it skype time yet?
[22:04] <abentley> rockstar: sure.
[22:04] <wgrant> I had a whole lot of translation-related failures in one of my branches overnight.
[22:04] <wgrant> Are those known?
[22:04] <wallyworld> rockstar: yep
[22:15] <rockstar> abentley, wallyworld, my mic no longer works, because it accidentally got unplugged and pulse is a stubborn bugger.
[22:17] <rockstar> abentley, wallyworld, thanks!
[22:18] <lifeless> rockstar: pkill npviewer.bin + check in the sound prefs that its not muted.
[22:19] <rockstar> lifeless, yeah, but when it already thinks there's a connection, it won't reset it.
[22:22] <flacoste> lifeless: done with what?
[22:22] <lifeless> flacoste: edits to the production process docs
[22:22] <flacoste> lifeless: ah, cool, i'll review the notifications email later :-)
[22:22] <flacoste> abentley: did you sort out your QA issue?
[22:22] <lifeless> flacoste: we'll need to do another pass once qastaging is actually live.
[22:36] <maxb> Anyone: what's the status of the erroneous-superseding issue?
[22:38] <lifeless> in buildbot
[22:38] <lifeless> 40 minutes to go
[22:38] <lifeless> when that completes we can CP it
[22:39] <lifeless> and then we need to do a db update to change data to be right
[22:39] <lifeless> wgrant has details
[22:40] <wgrant> I don't know the CP status, obviously.
[22:40] <wgrant> We will revert most of the publications to Published this evening. But some older PPA ones will need more manual recovery.
[22:40] <lifeless> wgrant: naturally, I mean the db repair
[22:40] <wgrant> But the ~launchpad PPA is fixed now, anyway.
[22:46] <lifeless> bugger
[22:46] <lifeless> 	twisted.internet.error.ProcessExitedAlready:
[22:46] <lifeless> where was the fix for that?
[22:47] <wgrant> I've only seen that from a buildd.
[22:48] <lifeless> bigjools mentioned it as a known test failure in devel, which was fixed
[22:48] <lifeless> we need to port the fix to prod-devel.
[22:55] <gary_poster> deryck: ping?
[22:55] <deryck> hi gary_poster
[22:56] <gary_poster> hey deryck.  I'm trying to get my triaging in order.  What's the story of this one: https://bugs.edge.launchpad.net/lazr.restful/+bug/443217
[22:56] <_mup_> Bug #443217: Changing a bug's affected project or description doesn't ever finish <bug-page> <dhrb> <javascript> <ui> <lazr.restful:New> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/443217>
[22:56] <gary_poster> it looks like Tom was working on it and had a handle on it, but of course, Tom is off doing other Tom things now
[22:56] <deryck> gary_poster, it's actually very close to next on our queue.  It's the next card on the backlog.
[22:56] <gary_poster> ah ok cool
[22:57] <gary_poster> is it a lazr.restful bug?
[22:57] <deryck> gary_poster, I think it can be fixed in lp.  But I left the task new until we could look more closely at it.
[22:58] <gary_poster> ok deryck.  um...since I'm trying to get rid of "New"s...would "Incomplete" be a reasonable description of the lazr.restful part of the task?  I guess that seems kind of artificial, but it reflects reality in that I shouldn't have anyone look at it yet, AFAICT.  Would that be ok?
[22:59] <deryck> gary_poster, yeah, fine with me.  We should make a call on it before it expires.
[22:59] <gary_poster> cool, thanks deryck
[22:59] <deryck> np!  Thank you.
[23:08] <wgrant> Were there any known translations failures overnight?
[23:14] <lifeless> wgrant: could you perhaps look for that bugfix he talks about ?
[23:14] <lifeless> wgrant: and I will shepard it into prod devel
[23:15] <wgrant> lifeless: Any idea when it was from?
[23:16] <lifeless> his sprint with jml I think
[23:16] <lifeless> or since
[23:16] <wgrant> Which rev was last mass-CP'd?
[23:17] <lifeless> we're fully deployed up to (inclusive) 11609
[23:17] <lifeless> flacoste: no, abentley oculdn't qa completely, blocked on puloads on staging not working
[23:17] <lifeless> flacoste: lamont was going to look at it
[23:21] <wgrant> lifeless: I see nothing particularly relevant since then.
[23:21] <wgrant> There were a couple of things moved around due to the sprint.
[23:21] <wgrant> But that's about it.
[23:21] <lifeless> ah
[23:21] <lifeless>  r11594
[23:21] <lifeless> which we have
[23:22] <wgrant> Ah, yes, that one.
[23:27] <sinzui> bryceh, ping
[23:29] <bryceh> sinzui, yep
[23:29] <sinzui> bryceh, do you see an administer link on https://edge.launchpad.net/~bryce ?
[23:29] <bryceh> sinzui, yes
[23:29] <bryceh> sinzui, 'Administer' and 'Administer Account'
[23:31] <wgrant> deryck: Woah, I just got seven emails from you.
[23:31] <sinzui> bryceh, you can use Administer to change that name...
[23:31] <lifeless> StevenK: I've just mailed canonical-lp about the prod-devel bb failure, can you perhaps investigate? you know more than I about that area.
[23:31] <deryck> wgrant, you must own 7 projects on lp. :-)
[23:31] <wgrant> Ah, missed that detail.
[23:31] <wgrant> Indeed.
[23:31] <sinzui> bryceh, but to change your id to bryce, you need to *delete* all you PPAs. You can create new ones, but they cannot have the exact same name.
[23:32] <sinzui> bryceh, that may be too drastic of a step for you to take
[23:33] <lifeless> afk- lunch and firewood stacking
[23:34] <bryceh> sinzui, ok, that may be ok.  Would it also require re-joining groups / mailing lists, or will those memberships get transitioned?
[23:34] <sinzui> bryceh, nothing else. changing your launchpad id does not change your db id.
[23:35] <sinzui> bryceh, the PPA restriction is because you have a public URL attached to the PPA
[23:35] <sinzui> bryceh, I know of one user who deleted his PPAs, then a day later we got complaints that those PPAs went missing
[23:35] <bryceh> sinzui, ok
[23:36] <bryceh> sinzui, since I've been on launchpad the past 5 months I think all my ppas are basically stale by now.
[23:36] <bryceh> anything "permanent" I've tended to put into a team ppa rather than my own.  So I think I'm safe, but that's good to know.
[23:36] <sinzui> okay.
[23:37] <sinzui> I wish we could know how many subscribers we have.
[23:39] <wgrant> The code is all there for number of package downloads.
[23:41] <bdmurray> sinzui: I'm having some issues with my branch regarding permissions for official bug tags - it seems to be the security checker is never used
[23:43] <sinzui> bdmurray, :( So while the view has always had a rule for IOfficialBugTagTargetRestricted, the security checker for IOfficialBugTagTargetRestricted is not used. I assume the IProduct launchpad.Edit is used?
[23:44] <sinzui> wgrant, the code is there, but the logs are not being parsed?
[23:44] <wgrant> deryck: You didn't notify owners of projects where the flag was disabled?
[23:44] <wgrant> sinzui: Correct.
[23:44] <wgrant> I landed the code in March, but some performance issues took a while to fix.
[23:46] <deryck> wgrant, I notified bug supervisors if there was one at first, thinking if one was set that was the preferred contact for something like this.
[23:46] <deryck> wgrant, stupid me, the bug supervisor can't change the setting.
[23:47] <wgrant> deryck: I didn't get an email for some of my team-owned projects.
[23:47] <wgrant> But I suppose they might have had the flag disabled.
[23:48] <deryck> wgrant, ah right.  Yes, if they already had this disabled, you would not have been contacted at all.
[23:52] <bdmurray> sinzui: I'm adding the security checker for IOfficialBugTagTargetRestricted so yes I believe IProduct launchpad.Edit is currently used
[23:53] <sinzui> bdmurray, can you pastebin the checker addition?
[23:54] <wgrant> It will use the most specific adapter.
[23:54] <wgrant> There is no way around it.
[23:54] <bdmurray> sinzui: http://bazaar.launchpad.net/~brian-murray/launchpad/modify-official-bug-tags-permissions/revision/11593
[23:54] <wgrant> (unless you have the tag stuff on a separate object, or use a different permission name)