[00:01] <wgrant> lifeless: It's actually much easier than that.
[00:02] <wgrant> Use self.request.stepstogo.consume()
[00:05] <sinzui> wgrant: mumble?
[00:06] <wgrant> sinzui: I'm there.
[00:06] <wgrant> ... but in the wrong room.
[00:06] <sinzui> I think my audio is buggered again. I will leave and return
[00:06] <wgrant> I can hear you.
[00:28] <wgrant> lifeless: QuestionMessage doesn't have indices in the DB.
[00:29] <lifeless> wgrant: well then.
[00:29] <lifeless> wgrant: it needs them or spam marking is racy
[00:33] <jtv> wgrant: any idea why the df app server wasn't running?
[00:34] <wgrant> jtv: None.
[00:34] <jtv> Oh well, I started it.
[00:34] <wgrant> Well, unless "bigjools" is an idea.
[00:34] <wgrant> Also, it's 9:30am here, you should not be here.
[00:35] <lifeless> jetlag
[00:38] <jtv> 'zcly
[00:38] <jtv> Plus, my UPS can't sleep.
[00:41] <wgrant> lifeless: Try to assign/unassign a private bug on qastaging.
[00:41] <lifeless> wgrant: why?
[00:42] <wgrant> lifeless: Because it crashes for me.
[00:42] <lifeless> what bug were you trying on
[00:43] <wgrant> 1234
[00:43] <lifeless> Indirect subscribers found on private bug. A private bug should never have implicit subscribers!
[00:43] <wgrant> Yes.
[00:44] <wgrant> Can you change status/importance?
[00:44] <lifeless> win
[00:44] <wgrant> They OOPS for me without a traceback.
[00:44] <wgrant> But it's possibly just a timeout.
[00:44] <lifeless> OOPS-1955QASTAGING103
[00:44] <lifeless> ID:OOPS-1955QASTAGING104
[00:44] <wgrant> Yeah, been waiting for a sync for a while :(
[00:44] <lifeless> 3 seconds, not a timeout
[00:44] <wgrant> Thanks.
[00:44] <lifeless> uhm
[00:45] <lifeless> is ~launchpad in malone-alpha
[00:45] <lifeless> no
[00:45] <wgrant> But I am.
[00:46] <lifeless> so i'm getting this with the 'normal' notification stuff
[00:46] <wgrant> On qas.
[00:46] <lifeless> yes
[00:46] <wgrant> It works fine on dev.
[00:46] <wgrant> I wonder if a custom filter has to exist.
[00:48] <wgrant> I also wonder if it's related to the fix for bug creation subscribers.
[00:48] <wgrant> If I can find it...
[00:49] <wgrant> No.
[00:50] <lifeless> now, is indirect 'via a team' or 'via a pillock' ?
[00:50] <wgrant> Pillar.
[00:50] <wgrant> Not team.
[00:50] <wgrant> fuuu
[00:50] <lifeless> ECONFUSINGTERMINOLOGY
[00:50] <wgrant> lazr.restful suppresses the traceback.
[00:50] <wgrant> Let's use non-AJAX...
[00:50] <lifeless> theres a bug on that
[00:50] <wgrant>  OOPS-1955QASTAGING107
[00:51] <wgrant> Module lp.bugs.subscribers.bug, line 151, in add_bug_change_notifications
[00:51] <wgrant> level=BugNotificationLevel.METADATA)
[00:51] <wgrant> Module lp.bugs.model.bug, line 1050, in getBugNotificationRecipients
[00:51] <wgrant> "Indirect subscribers found on private bug. "
[00:51] <wgrant> AssertionError: Indirect subscribers found on private bug. A private bug should never have implicit subscribers!<br />
[00:51] <wgrant> Not too helpful.
[00:51] <wgrant> But it's something.
[00:51] <wgrant> Surely not.
[00:51] <wgrant> This would have been broken for weeks.
[00:52] <lifeless> I envy you; you're getting to code.
[00:52] <wgrant> You're not?
[00:53] <lifeless> I'm architecting at the moment
[00:53] <lifeless> https://dev.launchpad.net/ArchitectureGuide/Services
[00:53] <lifeless> which is harder than you might think
[00:53] <wgrant> Ah, yes.
[01:02]  * wgrant comes dangerously close to deleting bug heat.
[01:02] <lifeless> \o/
[01:02] <lifeless> which reminds me
[01:03] <lifeless> to do an analyse of bug heat top-20 or whatever with and without decay
[01:03] <lifeless> I'm totally convinced that in successful projects the sort order is identical
[01:03] <lifeless> but ENEEDSDATA
[01:17] <LPCIBot> Project windmill-devel build #56: STILL FAILING in 1 hr 15 min: https://lpci.wedontsleep.org/job/windmill-devel/56/
[01:31] <jtv> StevenK, perhaps you would care to review a small fix for automatic index creation in publish-ftpmaster?  https://code.launchpad.net/~jtv/launchpad/bug-780214/+merge/60444
[01:36] <LPCIBot> Project db-devel build #531: FAILURE in 5 hr 20 min: https://lpci.wedontsleep.org/job/db-devel/531/
[01:40] <jtv> Or wgrant maybe?  Need a small fix reviewed.
[01:47] <jtv> No antipodeans in the review market today?
[01:48]  * wgrant returns.
[01:49] <wgrant> jtv: What creates that normally?
[01:50] <jtv> wgrant: I don't even know tbh
[01:50] <wgrant> Also, why always PRIMARY, never PARTNER?
[01:51] <wgrant> generateConfigForPocket does this.
[01:51] <wgrant> As long as it's given some components.
[01:51] <wgrant> I presume this failed on DF?
[01:51] <jtv> There are no separate PARTNER runs for this, as far as this script is concerned, so it uses PRIMARY as the place to keep track.
[01:51] <LPCIBot> Project windmill-db-devel build #255: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/255/
[01:51] <jtv> Yes.
[01:52] <wgrant> Do you still have the traceback?
[01:52] <jtv> I can make one.  Hang on.
[01:54] <jtv> wgrant: http://librarian.dogfood.launchpad.net/71105515/hyYRRP1nMvTD9b3OKTaVtUZy789.txt
[01:54] <wgrant> jtv: querulous hasn't been initialised, has it?
[01:54] <jtv> Nope
[01:54] <wgrant> It has no components.
[01:54] <wgrant> There's a bug for that.
[01:55] <wgrant> But why are you writing out indices before initialisation?
[01:56] <jtv> Skipping a few steps in testing, I guess.
[01:57] <wgrant> So this won't be the case in production?
[01:57] <wgrant> what triggers the index generation?
[01:57] <jtv> publish-ftpmaster.
[01:57] <wgrant> That's what runs it.
[01:57] <wgrant> In what case does it run?
[01:59] <jtv> wgrant: little accident with chat window here...  index generation is triggered by publish-ftpmaster being run on the distro and seeing that one or more suites in a frozen series do not have indexes yet.
[01:59] <wgrant> jtv: Hmm, that's too early.
[01:59] <wgrant> It needs to wait until it's been populated.
[02:00] <wgrant> Bug #675042 covers the bug that you've fixed here, but it reveals that it's being run too early.
[02:00] <_mup_> Bug #675042: Release file generation fails for series without components <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/675042 >
[02:00] <lifeless> tsekci times
[02:00] <wgrant> Pardon?
[02:00] <lifeless> just being silly
[02:01] <lifeless> a riff on other interpretations of 'populated'
[02:01] <jtv> wgrant: you are taking into account that publish-ftpmaster will not be running around the time a new series is created?
[02:02] <wgrant> jtv: Hm, why not?
[02:02] <wgrant> He's good at that.
[02:03] <wgrant> 11:02:06 < wgrant> jtv: Hm, why not?
[02:04] <wgrant> We currently stop the publisher so the manual index generation can be run.
[02:05] <wgrant> If we're doing the manual index generation automatically, there's not much point stopping the publisher.
[02:06] <jtv> My understanding is that stopping the various cron jobs was still needed for other reasons as well.
[02:07] <wgrant> That sounds like a temporary situation that we don't want to add more reasons to.
[02:07]  * wgrant invokes StevenK.
[02:12] <jtv> wgrant: when we get close to the point where the cron jobs no longer need to be disabled, we'll also have a better view of what else is needed to manage the various jobs that need to be done.
[02:13] <StevenK> wgrant: Oh?
[02:13] <wgrant> StevenK: Why do we still have the publisher off during initialisation?
[02:14] <StevenK> I hadn't done any work on it -- but we don't want to publish a half-initialised series
[02:14] <wgrant> jtv: Regardless, this fix should probably be in ftparchive.py. And it's almost tempting to keep the crasher to indicate that something has gone wrong.
[02:14] <wgrant> StevenK: Sure, but that's probably better handled by IDS signaling that it's finished and enabling publication of the series.
[02:15] <StevenK> Agreed
[02:16] <jtv> How do you enable publication of a series?  I thought that was per-distro.
[02:16] <wgrant> Perfect may be the enemy of good and all that, but perfect is not difficult here, and making it easier to silently do things wrong is also the enemy of good.
[02:17] <wgrant> jtv: Indeed, but that doesn't make much sense.
[02:17] <jtv> What is "that" in this case?
[02:18] <wgrant> jtv: DistroSeries needs an "initialised" flag or so. At the moment we have series like p-series sitting around and only not being published because they have nothing to publish.
[02:18] <wgrant> The publisher should only consider initialised series.
[02:18] <wgrant> And that solves this problem.
[02:18] <jtv> This is separate from the "initialised" flag on DSP, I take it.
[02:18] <wgrant> I don't think that flag should exist.
[02:19] <wgrant> But perhaps it should.
[02:19] <jtv> That's actually a recurring problem here, I think.
[02:19] <wgrant> Oh?
[02:19] <jtv> A proliferation of status flags for what is really a process flow.
[02:19] <StevenK> That's why I think it should be a DBEnum
[02:19] <wgrant> The larger problem is that it is apparent nobody has though about how this is all going to work.
[02:19] <wgrant> s/though/thought/
[02:19] <jtv> Exactly.
[02:20] <lifeless> thinking is overrated
[02:20]  * lifeless goes back to thinking
[02:20] <StevenK> I don't think it belongs on IDistroSeries, but only because it's enormous.
[02:20] <wgrant> I have thought about fixing DS.status.
[02:20] <wgrant> It is possible taht we could reuse that.
[02:21] <wgrant> We need to think how it will interact with Debian.
[02:21] <wgrant> But it seems reasonable.
[02:21] <lifeless> StevenK: I don't think thats a good reason not to do it
[02:22] <lifeless> StevenK: thats a good reason to make it smaller, but if you hold of on genuine improvements because its not [yet] small, you hamstring yourself.
[02:22] <lifeless> StevenK: you could say 'we won't make it bigger' and go yak shaving to make it smaller to let you put this field in and keep it hte same size
[02:22] <wgrant> jtv: I am really worried that there is no design for any of this.
[02:22] <wgrant> jtv: It's just a set of cards.
[02:22] <wgrant> jtv: With people working it out as they go.
[02:22] <lifeless> but that seems like saying 'making the class smaller is more important than making this part of the process reliable' - which I wouldn't agree with.
[02:23] <jtv> wgrant: same here, but I'm not a big fan of chucking in an enum right away either.
[02:23] <wgrant> jtv: Sure, we should actually talk about this.
[02:23] <wgrant> With Julian and stuff.
[02:23] <jtv> Yes.
[02:23] <jtv> I think we're sort of racing past an underlying problem,
[02:23] <wgrant> Rather than just piling more hacks onto the pile of hacks that is already a significantly larger pile than before DDs.
[02:23] <jtv> which is that we don't have a clear map of the dependencies between actions.
[02:24] <jtv> We have the current Ubuntu process, which is a serialization of actions--out of some set of possible ones.
[02:24] <wgrant> Riht.
[02:25] <jtv> So I'm thinking: the first thing we ought to do is figure out what the dependencies are.
[02:25] <jtv> Which is hard, and involves goat sacrifice.
[02:25] <wgrant> That sounds dangerously close to planning ahead of time...
[02:25] <jtv> Or some other way of seeing into the nether realm of soyuz.
[02:26] <jtv> Planning what ahead of what time?
[02:26] <wgrant> A feature.
[02:26] <wgrant> Or development thereof.
[02:27] <jtv> ?
[02:28] <jtv> I'm saying we should understand what it is that we're already doing.  That doesn't strike me as premature feature development planning.
[02:28] <StevenK> jtv: wgrant is showing his bitterness again.
[02:28] <jtv> He's too young to be bitter.
[02:28] <jtv> (For a non-Windows user, that is)
[02:28] <wgrant> It was a derogatory implication that much of this work lately has been quickly patching over immediate problems without considering the underlying problems.
[02:30] <wgrant> Some post-release updates need to go to -updates? Hardcode -updates when datereleased is set! We need to create distroseries indices after a series has been initialised? We turn the publisher off during initialisation because we haven't quite fixed that yet, so we can just assume the publisher will be off!
[02:30] <wgrant> etc.
[02:30] <wgrant> The feature was initially planned well, but the issues that have cropped up during development have had no planning at all.
[02:30] <wgrant> And this is how Soyuz got as bad as it is now.
[02:31] <jtv> I think these are two separate issues though.
[02:31] <jtv> The new requirements were thrown into the design in a hurry.  Very bad.
[02:32] <jtv> But what we were discussing is old design, and there a few hackish small steps may actually bring us to a better ultimate situation.
[02:33] <wgrant> But there has been no consideration of the ultimate solution before implementing the hackish small steps.
[02:33] <wgrant> So we don't know if we're going in the right direction.
[02:33] <wgrant> Or if we're going the direction soyuz did for its first three or so years.
[02:34] <jtv> Part of the problem is that we don't know what the ultimate initialisation procedure for a new series will look like.
[02:34] <wgrant> (which was possibly not unreasonable, due to time constraints, but that's not the case here)
[02:34] <wgrant> jtv: We need to sit down and work that out, I guess.
[02:35] <jtv> But I suspect trying to design that up front may lead us to decisions that turn out to be wrong at a later stage.  In which case it's more effective to let a pattern emerge first, and then design for the pattern.
[02:36] <wgrant> What is in question?
[02:37] <lifeless> wgrant: this isn't how soyuz got to its current state
[02:37] <wgrant> lifeless: Oh?
[02:38] <wgrant> Parts of it are very clear layers of hacks.
[02:38] <lifeless> yes
[02:38] <wgrant> Much moreso than the rest of LP.
[02:40] <lifeless> wgrant: there was a lot of BDUF done early on
[02:40] <lifeless> wgrant: and it was wrong and never corrected
[02:40] <wgrant> Sure.
[02:40] <wgrant> I'm not asking for BDUF on that scale.
[02:40] <wgrant> I am asking for a minimal amount of design.
[02:40] <lifeless> wgrant: I'm arguing that that is the root cause of many of the hacks
[02:40] <wgrant> Not 5-year speculative design like Soyuz.
[02:40] <wgrant> Hmm.
[02:41] <wgrant> Partly, yes.
[02:41] <wgrant> But not entirely.
[02:41] <lifeless> now, subsequent work hasn't fixed the root issues, and has yes papered over stuff
[02:42] <lifeless> I'm all for aiming for a good design and root cause fixes
[02:42] <lifeless> I don't think you're wrong to argue that some more analysis is needed
[02:42] <lifeless> I think its false to say that incremental development got us here
[02:42] <lifeless> what got us here was overly focused designs that didn't address the root causes which /made/ the basic facilities hard to reuse.
[02:43] <lifeless> for instance, picking something arbitrary we publish archives in two different ways for no good reason
[02:44] <StevenK> That's because Celso got cold feet about NMAF.
[02:44] <wgrant> No.
[02:44] <wgrant> PPAs need to be done, NMAF wasn't fast or complete enough for primary.
[02:44] <wgrant> Completion never happened.
[02:44] <wgrant> Nothing about getting cold feet.
[02:45] <StevenK> Ah. And since it worked fine for PPAs, it was good enough.
[02:45] <lifeless> or we could have used apt-ftp for ppas [with different tradeoffs]
[02:45] <wgrant> It turns out it didn't work fine, but the minor additional fixes were made.
[02:45] <wgrant> But yes.
[02:45] <lifeless> but the choice to bring in a different stack was done with sprints and design; the underlying issue wasn't, and hasn't been addressed.
[02:46] <wgrant> lifeless: For big stuff like that, yes, incremental development is not at fault. But there are so many special-cases and other gross hacks throughout Soyuz which are labelled as temporary hacks that will be discussed at $nextsprint, dated 2005 or 2006.
[02:47] <lifeless> wgrant: I think that shallower stuff is due to the overall 'we don't get to finish things' issue.
[02:47] <lifeless> wgrant: I give you e.g. blueprints
[02:47] <lifeless> :)
[02:47] <wgrant> lifeless: And we still don't get to finish things.
[02:47] <wgrant> Even with feature squads.
[02:47] <lifeless> thats interesting
[02:47] <lifeless> I thought we were doing a lot better
[02:48] <wgrant> We set a deadline for feature completion weeks beforehand.
[02:48] <wgrant> Then the last couple of weeks are very conservative.
[02:48] <lifeless> I think you should raise this on one of the two lp dev lists
[02:48] <wgrant> Feature completion is not based on completion of the feature.
[02:50] <lifeless> we have a glass display case for well, glasses
[02:50] <lifeless> it has a bottom draw thats wood
[02:50] <lifeless> so the glass starts about 25/30cm from the floor
[02:51] <lifeless> our newest kitten tries to jump into the cabinet
[02:51] <lifeless> so there is this patter patter patter ... THUMP
[02:51] <wgrant> Ahaha.
[02:51] <lifeless> as he propels himself up that 30cm gap aiming at where he can see stuff... and whacks into the glass front
[02:51] <wgrant> Smaaart.
[02:52] <wgrant> Wait, newest kitten? You have acquired multiple now?
[02:52] <lifeless> we have 2 (the desired number) now
[02:52] <StevenK> And then shakes himself off and goes to lay in the sun?
[02:52] <wgrant> Sun in NZ? lol.
[02:52] <StevenK> Oh. Right.
[02:52] <StevenK> s/sun/slightly warmer bit/
[02:52] <lifeless> sun, no. chases the other cat, then tries again a bit later
[02:53] <wgrant> (although it was around 0 here this morning, so I guess I can't really talk)
[02:53] <StevenK> It was 10 degrees when I went to bed
[02:53] <StevenK> That's cold enough
[02:54] <wgrant> Yay, bug heat timeouts on production now.
[02:55] <wgrant> OOPS-1956BA33
[02:56]  * StevenK waits the 30 seconds that OpenID seems to take
[02:57] <StevenK> Sigh, searching for oops makes me sigh
[02:59] <jtv> wgrant: some prolonged disconnectivity there...  What is in question?  Well currently, how we trigger and track the various steps in setting up a new series.
[03:01] <wgrant> jtv: Right, but why can this not be determined now?
[03:03] <jtv> I'm on thin ice there, but perhaps because so many things are shifting: we're generalizing beyond Ubuntu, IFP is becoming a job, we're introducing multiple parent relationships.
[03:04] <wgrant> Right.
[03:04] <wgrant> And the LEP basically only specifies +localpackagediffs UI.
[03:05] <jtv> You'll hear no argument from me there...
[03:05] <wgrant> Oh!
[03:05] <jtv> ?
[03:05] <wgrant> Someone agrees that the design is insufficient :)
[03:06] <jtv> I've been saying that for quite a while now I think.  You may not have heard all of it because it was on team calls.
[03:07] <wgrant> I have seen nothing other than a continuous stream of branches that reveal woefully inadequate design.
[03:07] <wgrant> I am glad that there has been some discussion or at least realisation that this is the case :()
[03:07] <jtv> But again, I see different considerations for the design we inherited and the one we're trying to implement.
[03:07] <wgrant> *:)
[03:08] <jtv> I don't think anyone particularly disagrees that we have a hurried design and it's not exactly a work of fine art.  But what we _do_ about it is another kettle of fish altogether.
[03:10]  * wgrant sighs and lunches.
[03:22] <wgrant> 3 rollbacks in 24 hours :(
[03:23] <spm> new record?
[03:23] <wgrant> I think so, yes.
[03:23] <wgrant> We've had two a couple of times. But not three.
[03:30] <spm> silver lining - is new record in our QA process to ensure that quality code lands on the LP prod branch. We're not afraid to rollback bad versions on discovery!
[03:32] <wgrant> Heh
[04:04] <lifeless> waheeee
[04:04] <lifeless>  548 KeyError: 56589
[04:08] <jtv> that's expressing just plain disdain for humans
[04:08] <wgrant> lifeless: That's the send-bug-notifications crap.
[04:08] <wgrant> You might have noticed there were tens of thousands of them yesterday.
[04:09] <wgrant> It is happy now.
[04:14] <lifeless> kk
[04:14] <lifeless> thanks
[04:16] <lifeless> is wallyworld doing uds?
[04:20] <wgrant> lifeless: The first couple of days, I think.
[04:21] <wgrant> Ian Booth
[04:21] <wgrant> 2011-05-09 till 2011-05-10
[04:21] <lifeless> thanks
[04:21] <wgrant> jtv: Hi.
[04:22] <wgrant> https://answers.launchpad.net/launchpad/+questions?field.search_text=&field.sort=RELEVANCY&field.sort-empty-marker=1&field.actions.search=Search&field.language=en&field.language-empty-marker=1&field.status=OPEN&field.status=NEEDSINFO&field.status-empty-marker=1 has four questions assigned to Launchpad Translations Administrators/Coordinators. Who is meant to handle that sort of thing now?
[04:23] <lifeless> aren't we all rosetta admins now?
[04:23] <jtv> Yes
[04:23] <jtv> hi wgrant... my life is so nice and interruption-free now that I'm no longer notified of messages
[04:23] <wgrant> Some of these are policy.
[04:23] <wgrant> Heh.
[04:24]  * jtv looks
[04:25] <jtv> By the way, Launchpad Translations Coordinators are a very different team.  They run our reference translation group.
[04:26] <jtv> Of the ones for rosetta admins, one is in Needs Information.
[04:27] <jtv> Another actually should have been un-assigned.
[04:30] <wgrant> jtv: Right, I know they're a different group, which is why I was asking about them :)
[04:30] <wgrant> Because I doubt they watch LP questions.
[04:31] <jtv> Good point.
[04:34] <lifeless> I need a proof reader
[04:34] <lifeless> Someone that will read a doc and make a list of wtf moments to give to me
[04:40] <lifeless> wgrant: tag, you're it ^, if you have time.
[04:41] <wgrant> I'm not going to get any useful code done today, so I might as well.
[04:41]  * wgrant looks.
[04:44] <jtv> wgrant: you were right by the way--IFP fixed my directories problem.
[04:45] <wgrant> jtv: Great.
[04:45] <wgrant> jtv: Are bug #55211 and bug #777941 deployable?
[04:45] <_mup_> Bug #55211: shouldn't require careful publisher run when cloning new released distrorelease <derivation> <lp-soyuz> <new-release-cycle-process> <qa-needstesting> <soyuz-publish> <Launchpad itself:Fix Committed by jtv> < https://launchpad.net/bugs/55211 >
[04:45] <_mup_> Bug #777941: Create distroseries indexes from regular publisher run <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by jtv> < https://launchpad.net/bugs/777941 >
[04:45] <jtv> wgrant: yes, because we're not using that script yet anyway.
[04:46] <wgrant> That's what I thought. Thanks.
[04:46] <jtv> Also, I just got it working on df.  :)
[04:46] <wgrant> Excellent!
[04:48] <jtv> Now to fake those marker files for O.
[04:49] <jtv> Or rather, figure out whether we need to.
[04:50] <wgrant> Well, what's it going to do? A no-op index publication when we set it to frozen?
[04:51] <LPCIBot> Project windmill-devel build #57: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/57/
[05:11] <jtv> wgrant: I was told that doing a publish-distro -A on the suites at such a later stage would be harmful.
[05:13] <jtv> StevenK: where is IDerivedDistro as mentioned in bug 643369?
[05:13] <_mup_> Bug #643369: IDistroSeries.deriveDistroSeries() should use the security adapter <derivation> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/643369 >
[05:13] <wgrant> jtv: I don't believe that to be the case.
[05:13] <wgrant> It's not ideal.
[05:14] <wgrant> But it shouldn't break anything.
[05:14] <wgrant> Undesirable, but not harmful beyond possibly wasting a few minutes.
[05:14]  * jtv suffers a mild gust of despair from hearing these contradictory requirements
[05:15] <jtv> It's safe to run publish-distro -A on a series (and suites) that has already been published?
[05:15] <wgrant> Yes. It will do bad things if it's released, but frozen is not release.
[05:15] <wgrant> +d
[05:16] <wgrant> All it does it forces the pockets to be dirty.
[05:21] <jtv> wgrant: that doesn't sound so bad, for a one-off migration issue
[05:21] <jtv> Hmmm this looks useful: http://justinhalpern.tumblr.com/post/5135237870/office-e-mail-translator
[05:24] <wgrant> jtv: I hoped it would be something to de-Outlook HTML.
[05:25] <jtv> Alas.
[05:25] <jtv> wgrant: I'll ignore the marker files issue then, but leave it on the table for a double-check with jools.
[05:26] <wgrant> jtv: Sounds good.
[05:26] <jtv> Meanwhile, trying to make sense of bug 643369, which is marked as a high priority.  What is this IDerivedDistro it speaks of, and why should Ubuntu not count as one once it's marked as derived from Debian?
[05:26] <_mup_> Bug #643369: IDistroSeries.deriveDistroSeries() should use the security adapter <derivation> <lp-registry> <Launchpad itself:Triaged> < https://launchpad.net/bugs/643369 >
[05:26] <wgrant> jtv: Because 2005, that's why.
[05:27] <jtv> Ah yes, 2005, the explanation for everything.  :)
[05:28] <jtv> wgrant: still, what would determine whether a distro is an IDerivedDistro?
[05:28] <wgrant> I think the owner is a more sensible check, but using IDerivedDistro is stupid and wrong.
[05:28] <wgrant> IDerivedDistro itself is stupid and wrong.
[05:29] <wgrant> In its current definition, at least.
[05:29] <wgrant> I believe it's currently != ubuntu.
[05:29] <wgrant> Which is obviously crap.
[05:29] <jtv> So... debian would be an IDerivedDistro!?
[05:29] <wgrant> Yes.
[05:29] <wgrant> When it is in reality the only non-derived distro.
[05:29] <wgrant>         if self.name == 'ubuntu':
[05:29] <wgrant>             alsoProvides(self, IBaseDistribution)
[05:29] <wgrant>         else:
[05:29] <wgrant>             alsoProvides(self, IDerivativeDistribution)
[05:30] <StevenK> IDerivedDistro is effectively "Any distro which isn't Ubuntu"
[05:30] <wgrant> (From Distribution._init)
[05:30] <StevenK> jtv: I think that bug is hard to fix, too
[05:31] <jtv> Ah, "Derivative."  That's why I got no hits for "Derived."
[05:31] <wgrant> Ah, IDerivativeDistribution is, in its current form, used for Ubuntu-specific permissions.
[05:31] <wgrant> So you might want to rename it to IHaveBadlyDefinedUbuntuDrivers.
[05:32] <jtv> Heh
[05:33] <jtv> Maybe I shouldn't be working on this bug then, especially since it doesn't say why the change is needed.
[05:34] <wgrant> It's certainly not pressing.
[05:34] <jtv> It's marked as a high priority.
[05:34] <jtv> Unlike all other pending tasks.
[05:34] <StevenK> It's needed because currently you need to be a member of soyuz-team or an admin to derive a series. You should be a driver or owner of the destination d
[05:35] <jtv> Oh, that
[05:35] <StevenK> *distribution (since the series may not exist)
[05:35] <jtv> That's much clearer, thanks.
[05:59] <jtv> StevenK, wgrant: how weird to have deriveDistroSeries on DistroSeries...  I would have expected it to be on the derivative distribution.
[05:59] <LPCIBot> Project windmill-devel build #58: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/58/
[06:00] <StevenK> jtv: The DistroSeries you call it from is the one you're deriving from?
[06:00] <jtv> Yes.
[06:00] <jtv> But ISTM you only need read permissions on that.  The derivative distro is what you're appending to.
[06:00] <StevenK> Yes ...
[06:02] <jtv> And then it checks if the derived series you want to create may already exist, and if it does, initialize it.
[06:02] <StevenK> jtv: Completly seperate.
[06:03] <StevenK> jtv: We use the object were calling deriveDistroSeries() on as the parent series -- so it doesn't need to be fed into the argument list.
[06:03] <StevenK> And deriveDistroSeries() is happy enough to create the series if it can't find it.
[06:04] <jtv> Frightening.
[06:04]  * StevenK goes back to fixing tests
[06:05] <jtv> ISTM this wants to be a method on the parent Distribution plus a method on the derived DistroSeries, rather than a single method on the parent DistroSeries.
[06:06] <StevenK> What?! You're making no sense, and I'm getting cross.
[06:14] <wallyworld> wgrant: ping
[06:28] <wgrant> wallyworld: Hi.
[06:29] <wgrant> jtv: Possibly, but it may be sensible to do them in one operation sometimes.
[06:29] <jtv> Sensible or easy?
[06:29] <wallyworld> wgrant: i have had a go at moving the gpghandler stuff to the tac file but am unsure a) if it's correct and b) how to test. could you have a look?
[06:30] <wallyworld> wgrant: i've not seen or used the tac stuff before. here's a draft mp https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/60454
[06:30] <wgrant> wallyworld: I didn't do it myself precisely because I couldn't think of a quick way to test it.
[06:30] <wgrant> Twisted people and/or lifeless may have ideas.
[06:31] <wallyworld> wgrant: ok. what's the bit of code that event loads and runs the tac files?
[06:31] <wallyworld> even
[06:31] <wgrant> wallyworld: They're run by twistd.
[06:31]  * StevenK reads the MP and vomits
[06:31] <StevenK> Surely there HAS to be a better way
[06:31] <wgrant> wallyworld: See utilities/start-dev-soyuz.sh
[06:32] <wallyworld> wgrant: ok.
[06:32] <wallyworld> StevenK: you're welcome to tell me a better way
[06:32] <StevenK> Extending gpg handler that didn't use directory that gets reaped would be nice
[06:32] <wallyworld> StevenK: the bug report had a bit of discussion and what's been done seems to be the best that could be though of
[06:33] <wallyworld> StevenK: apparently there's issues with that approach
[06:34] <wgrant> We could possibly use /var/tmp. But this isn't *that* bad.
[06:34] <StevenK> I meant a IDaemonGPGHandler or so -- unless there is an easy way to overwrite methods
[06:34] <StevenK> wgrant: It's a hacky kludge, and it makes me sad.
[06:36] <wallyworld> StevenK: makes me sad too. but it seems to be the "accepted" approach according to the bug report comments
[06:37] <wgrant> wallyworld: I'd rename GPGHandler job to something more obvious, but apart from that it looks OK. Still not sure how to test.
[06:37] <lifeless> I don't think an integration test is worth doing
[06:38] <lifeless> tac files are astonishingly hard to test and I have never understood why they are way they are
[06:38] <lifeless> I always write regular functions
[06:38] <lifeless> and then make my tac files
[06:38] <lifeless> from foo import bar
[06:38] <lifeless> bar()
[06:39] <wallyworld> lifeless: ok. so doing it that way you just unit test bar separately
[06:42] <lifeless> right
[06:42] <lifeless> and take it on faith that the tac calls bar
[06:43] <lifeless> but you keep it to those literal two lines
[06:43] <lifeless> wallyworld: what was the architecture of the stuff @ caterpillar
[06:44] <lifeless> wallyworld: I mean, did you have one big tree like we do, or a bunch of small trees; did you write micro services or have a single big DB
[06:45] <wallyworld> lifeless: it was one big tree (project started over 10 years ago before EJB spec had even hit 1.0) but it's slow evolving to a more modular approach using stuff like OSGi
[06:45] <wallyworld> lifeless: there is currently a single Oracle instance but separate schemas for BI reporting etc
[06:46] <lifeless> wallyworld: I'm starting the socialisation process of this - https://dev.launchpad.net/ArchitectureGuide/Services - and given how recently you've joined the team, I think you'd make a good early-draft reader of it... if you have the time
[06:46] <lifeless> wgrant: did you have any feedback ?
[06:47] <wallyworld> lifeless: cool. will look.
[06:47] <wgrant> lifeless: I have no real suggestions for improvement. It's not yet really at a stage where I can tell you you're wrong.
[06:47] <wgrant> It looks very good so far.
[06:47] <lifeless> wgrant: s/you/if/?
[06:47] <wgrant> No.
[06:47] <lifeless> oh, right.
[06:48] <wgrant> +that, potentially.
[06:48] <lifeless> do you think I'm wrong and waiting for evidence, or hope I'm not but didn't find any (due to lack of concrete data)
[06:48] <wgrant> I believe you're right, and that page gives me no doubts.
[06:50] <LPCIBot> Project windmill-db-devel build #256: STILL FAILING in 1 hr 17 min: https://lpci.wedontsleep.org/job/windmill-db-devel/256/
[06:51] <lifeless> I think I need more pessimistic colleagues :)
[06:57] <wallyworld> lifeless: *very* brief look before going to breakfast - the proposal also needs to mention domain modelling changes - the sort of stuff we've discussed previously wrt business objects vs persistent objects. also inter-service apis which exchange object references need to do so using external/business key references etc. in short, this aspect is a whole topic worthy of discussion in the lep
[06:59]  * wallyworld off to breakfast
[07:00] <lifeless> wallyworld: those are good things to talk about
[07:00] <wgrant> But I don't think this is the place.
[07:00] <wgrant>  /stage
[07:01] <lifeless> wallyworld: on the latter I was assuming we'd use a locally unique key - its a well known and solved issue. On the former the template/api service would be sane, the current core would not change (but would lose all view code).
[07:01] <lifeless> wallyworld: so I concur with wgrant; I think those things are truely orthogonal to the business case
[07:07] <jtv> wgrant: why did you mark the bug for creating ds indexes from publish-ftpmaster as qa-untestable?
[07:08] <wgrant> jtv: Because it was about 30 seconds before you told me you'd tested it, and I wanted to clear up the QA state.
[07:08] <wgrant> Which is currently an unprecedented mess.
[07:09] <jtv> I thought our current procedure for "safe to deploy even if not actually Q/A'ed" was to mark the bug as qa-ok.
[07:09] <jtv> I'm asking because I could easily have missed a change.
[07:09] <lifeless> either is fine
[07:09] <lifeless> untestable is what --no-qa sets when you pass it to ec2 land
[07:09] <wgrant> I've been told off for using qa-ok for OK-to-deploy before.
[07:10] <lifeless> using qa-ok will add confusion if folk want to assess 'fixes bug' vs 'ok to deploy'
[07:10] <lifeless> when I say either is fine, I mean I don't care :)
[07:11]  * jtv wishes we had deploy-ok and so on
[07:15] <lifeless> someone just needs to do it - patch up qatagger
[07:19] <lifeless> wgrant: have you landed that backout?
[07:20] <wgrant> lifeless: Yes.
[07:20] <wgrant> Will be out of buildbot in a couple of hours.
[07:20] <lifeless> cool
[07:20] <wgrant> Thinking about it again I should have had buildbot killed.
[07:20] <lifeless> I'm just looking for a good rev to test this rabbit branch
[07:20] <wgrant> Since it landed soon after a new run had started.
[07:29] <LPCIBot> Yippie, build fixed!
[07:29] <LPCIBot> Project db-devel build #532: FIXED in 5 hr 52 min: https://lpci.wedontsleep.org/job/db-devel/532/
[07:42] <lifeless> man the pypy bug tracker is -fail- ui
[07:42] <lifeless> filing a new bug asks for a 'change note'
[07:43] <StevenK> Sounds like two bugs, then
[07:48] <lifeless> StevenK: well, they use roundup
[07:48] <lifeless> https://codespeak.net/issue/pypy-dev/issue718?@ok_message=msg%202507%20created%3Cbr%3Eissue%20718%20created&@template=item
[07:49] <wgrant> lifeless: ah, so you are trying lmirror on pypy?
[07:49] <StevenK> Ewwwww
[07:49] <wgrant> I was going to suggest that over rewriting it in Go.
[07:50] <lifeless> wgrant: I wanted to evaluate it yes
[07:50] <lifeless> wgrant: real    0m7.188s
[07:50] <lifeless> user    0m6.760s
[07:50] <lifeless> sys     0m0.390s
[07:50] <lifeless> vs
[07:51] <lifeless> real    0m9.227s
[07:51] <lifeless> user    0m8.880s
[07:51] <lifeless> sys     0m0.340s
[07:51] <wgrant> Which is which?
[07:51] <lifeless> to capture a delta of a mirror push on a 500K file tree whose shape was given by the ls -lr from archive.u.c
[07:51] <lifeless> wgrant: the faster one is pypy
[07:52] <wgrant> Right.
[07:52] <wgrant> Less good than I would have expected.
[07:52] <lifeless> wgrant: even with the extra 0.8 seconds from the parsing split
[07:52] <wgrant> Oh.
[07:52] <wgrant> Hmm.
[07:53] <wgrant> you probably really want an itersplit, anyway.
[07:53] <lifeless> yes
[07:53] <lifeless> I've rewritten the parser to use a generator, which was ~0 saving in cpython
[07:53] <lifeless> so I shelved it
[07:54] <wgrant> But could be massive in PyPy..
[07:54] <lifeless> yeah
[08:01] <StevenK> lifeless: Your bug report title says string.plit, by the way\
[08:02] <StevenK> s/\\//
[08:02] <lifeless> heh
[08:06] <jml> lifeless: awesome!
[08:09] <lifeless> jml: I know! and now we have a user we can't change the api!? :(
[08:09] <jml> lifeless: uhhh, I reckon we could work with him
[08:09] <jml> lifeless: also, we could just make something better & make it part of fixtures
[08:09] <lifeless> jml: yes, I was teasing about the API
[08:10] <lifeless> I'm sure he'd adapt to a nicer API if we get it togethe
[08:10] <lifeless> r
[08:10] <lifeless> I got mail from him out of the blue
[08:10] <lifeless> saying that this was nicer than the layer he had before
[08:13] <jml> :)
[08:25] <NCommander> What's the best way to create test packages for Soyuz? I need to implement a test suite which causes an arch-any/arch-all skew
[08:25] <NCommander> s/suite/case/g
[08:25] <wgrant> What are you trying to do?
[08:26] <lifeless> wgrant: with ec2 demo, should it appear to hang on buildout ?
[08:26] <lifeless> wgrant: or is it just -darn- slow?
[08:26] <wgrant> lifeless: No, but it will take several minutes.
[08:26] <wgrant> Unless you are asuka, then 30 minutes is common.
[08:27] <NCommander> wgrant: cause publisher to retain older binaries during an arch any/arch all skew which has been the primary cause of image breakage on armel
[08:27] <wgrant> NCommander: You should talk to the Soyuz developers about that first oh wait.
[08:27] <NCommander> wgrant: well I want the test case so I can show the problem before any solution is implemented
[08:28] <lifeless> wgrant: what should it do ?
[08:28] <lifeless> wgrant: end up in a shell? return to the prompt and wait for manual shutdown?
[08:28] <wgrant> NCommander: You don't want to use real packages for that. Use SoyuzTestPublisher.
[08:28] <wgrant> lifeless: It will tell you that the webapp is running now and then give you a Python REPL.
[08:28] <lifeless> wgrant: apparently not
[08:28] <wgrant> Lies.
[08:28] <NCommander> wgrant: I disagree, since the test validation should be if APT can still install packages from LP
[08:29] <lifeless> utilities/shhh.py PYTHONPATH= ./bin/buildout \
[08:29] <wgrant> NCommander: That's a very high-level complex integration test at a scale we do not currently have.
[08:29] <lifeless>                 configuration:instance_name=development -c buildout.cfg
[08:29] <lifeless> was the last I have seen from it
[08:29] <wgrant> lifeless: Is buildout eating CPU?
[08:29] <NCommander> wgrant: *grumble* :-/.
[08:29] <lifeless> NCommander: doing that is fine to demonstrate the problem
[08:29] <wgrant> NCommander: Can you imagine how slow the test suite would be if we did that for everything?
[08:29] <lifeless> NCommander: but its at a huge remove from the source of the issue
[08:29] <wgrant> But we are well aware of that problem.
[08:30] <wgrant> It does not require demonstration.
[08:30] <lifeless> NCommander: and there is a bug for this case already :P
[08:30] <NCommander> lifeless: was not aware of this, I was simply poking LP with a big stick to try and work towards this
[08:30] <lifeless> NCommander: cool
[08:30] <NCommander> lifeless: My initial idea was to simply implement the publishing algrothmin used by dak to retain old binaries until the arch any/all skew is resolved in unstable
[08:31] <NCommander> (and I poked cjwatson on it who pointed me to the original Debian spec on this subject)
[08:31] <wgrant> For us it's far easier than that.
[08:31] <NCommander> ?
[08:31] <wgrant> To fix it is basically a matter of deleting code.
[08:31] <wgrant> Since we explicitly supersede them atomically now.
[08:31] <lifeless> we do this deliberately you see :>
[08:31] <NCommander> lifeless: it causes a lot of issue with ARM ports.
[08:31] <lifeless> \o/ bug search timeouts
[08:31] <NCommander> (and to a lesser extent PPC)
[08:32] <lifeless>  OOPS-1956EB151
[08:32] <rvba_> stub: Hi and thanks for the review!
[08:32] <wgrant> rvba_: Hi. Did you get anywhere with your traversal?
[08:32] <NCommander> lifeless: wgrant: where's the existing LP bug?
[08:32] <lifeless> wgrant: is it bug 402935 ?
[08:32] <_mup_> Bug #402935: Domination of architecture independent binaries is not restricted to the source publication boundaries <boobytrap> <lp-soyuz> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/402935 >
[08:32] <wgrant> lifeless: No, but that would be fixed by this.
[08:33] <wgrant> lifeless: Because it's a bug in the code that would be deleted.
[08:33] <rvba_> wgrant: I'll start with that just now.
[08:33] <wgrant> rvba_: grep for stepstogo.consume
[08:33] <wgrant> rvba_: No need for an intermediate object.
[08:33] <rvba_> wgrant: ah ... I'll take a look at  stepstogo.consume, thanks!
[08:33] <lifeless> wgrant: do you know the bug fo rthis?
[08:34] <wgrant> Bug #34086
[08:34] <_mup_> Bug #34086: morguing arch-all packages can result in uninstallable binaries <feature> <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/34086 >
[08:34] <wgrant> Mmm, I guess it does have to be aware of dependencies, so it is a bit of work.
[08:35]  * NCommander notes that dak handles this now */comment*
[08:35] <lifeless> NCommander: thats nice dear :)
[08:35] <wgrant> Yes, but dak doesn't suck.
[08:35] <wgrant> And is improving.
[08:35] <wgrant> So it is doubly much better than LP.
[08:36]  * NCommander helped rewrite much of dak long ago :-/
[08:36] <lifeless> wgrant: hey, LP is improving
[08:36] <lifeless> NCommander: we'd love a patch for this for lp
[08:36] <NCommander> lifeless: I'd be glad to do the foot work, but I'm not a LP guru
[08:36] <StevenK> 'leg work' :-P
[08:36] <wgrant> lifeless: Yes, but glacially.
[08:36] <NCommander> this is the dak spec for how Debian fixed it http://ftp-master.debian.org/wiki/projects/arch-all-tracking/
[08:37] <NCommander> I think its probably pretty sane if we simply implement in a similar fashion
[08:39] <wgrant> "We remove all arch all packages that are not referenced by existing source packages but to be safe we always keep the newest version similar to the source removal case. The process is called 'old_and_unreferenced', too."
[08:39] <wgrant> That's not an entirely useful description of how referencedness is calculated.
[08:39] <lifeless> jml: the ec2 postmortem console is interesting
[08:39] <lifeless> jml: but it lies:
[08:39] <NCommander> wgrant: a lot about dak is simply looking at the code :-P
[08:40] <lifeless> EC2Instance is available as `instance`.
[08:40] <NCommander> er, is only explainable by looking at the code
[08:40] <lifeless> >>> instance
[08:40] <lifeless> Traceback (most recent call last):
[08:40] <lifeless>   File "<console>", line 1, in <module>
[08:40] <lifeless> NameError: name 'instance' is not defined
[08:40] <jml> lifeless: the postmortem console isn't my feature (although I probably broke it).
[08:40] <lifeless> jml: and here I was giving you undue credit :)
[08:41] <jml> lifeless: :)
[08:41] <NCommander> wgrant: I'm guessing the way to start is drafting a LP spec which describes how dak does it and how we want to implement their braindamage^W process
[08:42] <adeuring> good morning
[08:42] <lifeless> NCommander: uhm, probably not.
[08:43] <lifeless> NCommander: a LEP /may/ be useful, but probably isn't.
[08:43] <lifeless> NCommander: I'd refine the bug until its implementable, make sure you have input from experienced folk like Julian, and then start doing it.
[08:44]  * NCommander is beginning to under Soyuz's design ...
[08:44] <NCommander> *understand
[08:46] <wgrant> I think we probably want to undo ArchiveRemovalRedesign :(
[08:47] <NCommander> wgrant: what is ArchiveRemovalRedesign?
[08:47]  * NCommander is writting a comment on the bug
[08:47] <wgrant> NCommander: 2006 stuff.
[08:47] <lifeless> I've bumped the bug
[08:47] <wgrant> Which is mildly relevant here.
[08:47] <wgrant> I am pondering how this will work.
[08:47] <NCommander> lifeless: I'm also putting some comments on why this is important now
[08:47] <wgrant> We need to only drop things from the indices when all binaries from a source on a particular arch are superseded.
[08:48] <wgrant> Which probably means we need an intermediate status.
[08:48] <lifeless> wgrant: superseded-or-not-built-anymore
[08:48] <lifeless> wgrant: the dependency check is more accurate
[08:48] <wgrant> Which dependency check?
[08:48] <NCommander> Wouldn't the solution simply be keeping the old binaries published until superseeded?
[08:49] <StevenK> We do
[08:49] <NCommander> (i.e., change when the superseeded status is applied to a binary record)
[08:49] <wgrant> NCommander: They are superseded already.
[08:49] <lifeless> wgrant: modelling this as 'no version locked rdeps exist'
[08:49] <lifeless> NCommander: https://blueprints.launchpad.net/launchpad/+spec/archive-removal-redesign
[08:50] <wgrant> lifeless: That's taking it to another level entirely.
[08:50] <NCommander> lifeless: that's like making testing exist in Soyuz
[08:50] <StevenK> NCommander: You can make that joke only after fixing the testsuite
[08:51] <NCommander> StevenK: Debian testing
[08:51] <NCommander> not testing in general
[08:51] <StevenK> Testing does exist?
[08:51] <StevenK> Does it not?
[08:51] <lifeless> zomg
[08:51] <lifeless> celso wtf
[08:51] <NCommander> ... its like implementing britney's functionality in Soyuz
[08:51] <NCommander> Grumble
[08:51] <NCommander> lifeless: ?
[08:51] <wgrant> lifeless: Where?
[08:51] <lifeless> https://launchpad.canonical.com/SoyuzArchiveRemovalRedesign/ - see the explain analyze and assertions about fineness
[08:51] <StevenK> NCommander: We also run britney
[08:51] <wgrant> lifeless: Oooooh I can see the spec now.
[08:52] <NCommander> StevenK: yes, but we don't split out a specialize archive of packages that are only installable
[08:52]  * NCommander can't see that wiki page ...
[08:52] <StevenK> NCommander: Testing doesn't mean the package is installable, just that it built
[08:53] <StevenK> And it isn't a seperate archive, it's a seperate *series*
[08:53] <NCommander> StevenK: britney doesn't allow a package to migrate from unstable->testing unless its installable on all release-candidate architectures
[08:53] <lifeless> NCommander: click on 'login'
[08:53] <lifeless> NCommander: it should let you see it
[08:53] <NCommander> lifeless: yeah, figured that bit out
[08:54] <wgrant> lifeless: What about that assertion is particularly faulty?
[08:55] <wallyworld> wgrant: review? :-) https://code.launchpad.net/~wallyworld/launchpad/poppy-sftp-gpgconf/+merge/60454
[08:56] <lifeless> wgrant: seqscan == seqscan
[08:57] <lifeless> wgrant: both are horribly inefficient
[08:57] <lifeless> wgrant: as an assessment for its utility on production data (even of the time) its utterly useless
[08:57] <wgrant> lifeless: I didn't even consider the possibility that it was a seq scan, because that would just be stupid.
[08:57] <lifeless> wgrant: Aggregate  (cost=5909.43..5909.44 rows=1 width=0) (actual time=543.342..543.346 rows=1 loops=1)
[08:57] <lifeless>    ->  Seq Scan on securesourcepackagepublishinghistory  (cost=0.00..5754.15 rows=62112
[08:57] <wgrant> So I just looked at the filter and time.
[08:58] <wgrant> Impressive.
[08:58] <bigjools> securesourcepackagepublishinghistory?
[08:59] <lifeless> bigjools: I'm lamenting a previous performance analysis which I happened to run into fallout from just last week
[08:59] <lifeless> as in 'things are slow because of this'
[08:59]  * NCommander is getting in the feeling he's stepped into something old and crufty
[08:59] <wgrant> NCommander: What, you mean Launchpad? :)
[09:00] <NCommander> wgrant: heh
[09:02] <stub> Is it possible to reorder a bzr pipeline?
[09:09] <mrevell> Hello all
[09:44] <lifeless> wgrant: jml: ec2 demo seems reproducibly broken for me
[09:44] <wgrant> lifeless: Probably.
[09:44] <wgrant> It's not used very much.
[09:44] <wgrant> at all.
[09:47] <jtv> allenap, got a mo' to chat about PackageCopyJob?
[09:47] <allenap> jtv: Sure.
[09:48] <jtv> Thanks.  This is about the "only sync up to 100 packages" work.
[09:48] <allenap> jtv: Mumble or MS Skype?
[09:48] <jtv> If you put it like that, then mumble please.  :)
[09:51] <bigjools> MS Skype, lol
[09:51] <lifeless> bigjools: you've seen the news, right?
[09:52] <bigjools> yeah
[09:52] <bigjools> trying to work out what I can use instead
[09:53] <wgrant> Yeah, this could be interesting.
[09:54] <lifeless> its a damn shame
[09:54] <lifeless> their echo detection is awesome
[09:56] <bigjools> yes, it is
[09:57] <bigjools> the biggest problem for me is finding a skypeout replacement
[09:57] <lifeless> dial 9 for an outside line?
[09:57] <bigjools> jml!
[09:58] <bigjools> lifeless: if I can use that for personal calls as well, sure :)
[09:58]  * bigjools considers remaining critical bugs as just high on June 26th
[09:58] <StevenK> bigjools: Host asterisk on a VPS?
[09:59] <lifeless> bigjools: speaking of criticals
[09:59] <bigjools> so that jml gets a pie
[09:59] <lifeless> bigjools: I want to nuke that soyuz specific oops report
[09:59] <allenap> I have three Netgear land-line phones with Skype built-in. MS have pwned my base.
[09:59] <bigjools> lifeless: is there a way of including it in the prod report?
[09:59] <lifeless> bigjools: you've had a month or so of low oops counts in the main report to see if that wil lcause you grief or not
[09:59] <StevenK> allenap: :-(
[09:59] <lifeless> bigjools: the oopses are there
[09:59] <bigjools> lifeless: that's not the issue
[10:00] <bigjools> lifeless: the issue is that occasionally there's a ZOMG problem that is only apparent from that report
[10:00] <lifeless> bigjools: that applies to all services though
[10:00] <lifeless> bigjools: a spike of oopses is a problem
[10:00] <bigjools> lifeless: yes, but the single oops that we need to see is not visible enough buried in the other report
[10:00] <lifeless> bigjools: if you still need it, we'll leave it, but I fail to understand what makes it special
[10:00] <bigjools> visibility
[10:01] <bigjools> if you can guarantee that we'll see that single oops in the main report, I am very happy to lose one more email from my inbox
[10:01] <lifeless> we'd get -one- oops and it would be a zomger?
[10:01] <bigjools> the report is based around volume of oopses as opposed to their criticality
[10:01] <bigjools> yes
[10:02] <lifeless> how does that work?
[10:02]  * bigjools racks brain
[10:02] <lifeless> also, relatedly -  285 OperationalError: FATAL: Ident authentication failed for user "sync_packages" FATAL: Ident authentication failed for user "sync_packages"
[10:02] <lifeless> -really- needs fixing.
[10:02] <bigjools> allenap: ^
[10:02] <lifeless> like really really.
[10:03] <lifeless> it needs a config dir setup, the cronscript set to use that dir, with a new OOPS prefix, and the db user created.
[10:03] <lifeless> about 15 minutes work.
[10:03] <allenap> lifeless, bigjools: Rats, I meant to fix that last week. Sorry. I'll do that today.
[10:03] <lifeless> allenap: thank you
[10:03] <lifeless> bigjools: thanks!
[10:04] <bigjools> cheers allenap
[10:05] <bigjools> lifeless: I can't remember the specific instance now, sorry :(  But there have been times in the past where a single or few oopses would have been buried in a sea of timeouts in the main report.
[10:05] <lifeless> bigjools: kk, thanks for trying :)
[10:05] <bigjools> lifeless: what I'd like to see is all those routine oopses removed in the current reports, they should not be oopses, and then we could consider putting soyuz oopses at the top of the prod report.
[10:06] <bigjools> lifeless: the publisher has the odd problem where corrupt data is caught by an assertion once an hour
[10:07] <bigjools> lifeless: but believe me, fewer emails is good, I am all for that :)
[10:08] <lifeless> so lets leave the status quo for now
[10:18] <NCommander> wgrant: lifeless: so where do we go from here on re:arch-all/any?
[10:18] <lifeless> NCommander: code
[10:19] <lifeless> NCommander: and talk to julian
[10:20] <NCommander> lifeless: I guess I need to start with writing a test case ...
[10:29] <wgrant> check_permission in model code is still verboten, right?
[10:30] <wgrant> rvba_, bigjools: checkCopy calls check_permission... this is probably not legal.
[10:31] <wgrant> In fact, yeah, that's buggy.
[10:31] <bigjools> I can't remember why it's verboten
[10:31] <wgrant> It always checks the primary archiev.
[10:31] <wgrant> Fourth rollback in 24 hours woo.
[10:31] <bigjools> what are you looking at?
[10:31] <bigjools> rvba_ is no around this morning BTW
[10:32] <wgrant> bigjools: CopyChecker.checkCopy
[10:32] <wgrant> if reason is not None
[10:32] <wgrant> It checks launchpad.Append on the primary archive.
[10:33] <wgrant> Bad for at least two reasons:
[10:33] <bigjools> :/
[10:33] <wgrant>  1) check_permission in model is bad.
[10:33] <wgrant>  2) main_archive is mostly not the right thing.
[10:34] <wgrant> bigjools: What do you think?
[10:35] <bigjools> wgrant: main_archive is clearly wrong
[10:35] <bigjools> when we have self.archive
[10:36] <LPCIBot> Project windmill-db-devel build #257: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/257/
[10:36] <wgrant> bigjools: And I think using check_permission is a bad idea, given that the method takes a Person already.
[10:36] <bigjools> wgrant: agreed
[10:36] <wgrant> bigjools: I really don't want confusing security in this sort of code :)
[10:37] <bigjools> wgrant: agreed
[10:37] <wgrant> But rather than roll it back for a second time, I shall fix it.
[10:37] <wgrant> Or at least try to quickly.
[10:37] <wgrant> Should be a matter of deleting that block and adding check_permissions=False to the do_copy call in syncSource.
[10:37] <bigjools> wgrant: thanks
[10:38] <bigjools> wgrant: assuming the security adapter already DTRT
[10:39] <wgrant> bigjools: The security on syncSource hasn't changed.
[10:39] <bigjools> wgrant: where was the lp.append for security enforced, I can't remember
[10:39] <wgrant> bigjools: It's enforced by the Archive securityproxy.
[10:39] <wgrant> Archive.syncSource(s) is hidden behind launchpad.Append
[10:40] <bigjools> right
[10:40] <wgrant> They're on IArchiveAppend.
[10:40] <wgrant> Still.
[10:42] <bigjools> wgrant: goes to show, we need experienced soyuz people carefully checking soyuz branches :/
[10:42] <wgrant> bigjools: Surely not!
[10:43] <wgrant> There's a reason I'm not unhappy that most deploys happen during my day where I can watch :)
[10:44] <bigjools> heh
[10:45] <bigjools> wgrant: IIRC this was added because you said to rvb that security would lose lp.append without it
[10:46] <wgrant> bigjools: Yeah. But I intended that syncSource would call do_copy with check_permissions=False, to limit the security hack as far as possible.
[10:46] <wgrant> Not that check_permissions=True would handle the hack itself.
[10:46] <bigjools> ok
[10:47] <wgrant> (check_permissions=False turns off all the new code, so we just get the old behaviour)
[10:47] <poolie> hi all
[10:48] <bigjools> wfm
[10:48] <wgrant> Great, thanks.
[10:48] <bigjools> wgrant: we only want the new behaviour in the job
[10:48] <bigjools> hi poolie
[10:48] <bigjools> nice blue hair :)
[10:51] <lifeless> bigjools: so I think this is 'new to lp coding' not 'new to soyuz' - I've seen other similar thinkos
[10:52] <bigjools> lifeless: the reviewer missed it
[10:52] <lifeless> bigjools: yes, yes they did
[10:52] <bigjools> wgrant: we need to talk about build dependencies for multiple parents
[10:52] <bigjools> and our current schema
[10:53] <wgrant> bigjools: So we do.
[10:53] <wgrant> Do you want to mumble tonight?
[10:53] <bigjools> I was hoping to get jtv and StevenK involved too
[10:54] <bigjools> but yes
[10:56] <adeuring> stub: still around?
[10:59] <stub> adeuring: yes
[11:00] <adeuring> stub: I'm trying to figure out how to avoid the timeouts from bug 739075. AS I understand it, most time is spent in joining QuestionMessage and Message in order to find messages from given person
[11:00] <_mup_> Bug #739075: Person:+questions timeouts <timeout> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/739075 >
[11:01] <adeuring> stub: I'm wondering if we should add a column questionmessage.owner, simmilar to bugmessage owner
[11:01] <wgrant> adeuring: We fixed that for bugs recently by denormalising Message.owner onto BugMessage.owner
[11:01] <wgrant> That.
[11:01] <stub> adeuring: The way it was solved for BugMessage was to add an owner column
[11:01] <adeuring> right
[11:01] <wgrant> "recently" meaning "last week"
[11:01] <stub> adeuring: I'd work from that template. The garbo.py job is still there for you to cargo cult.
[11:01] <adeuring> ok, so I'll try that too for questions
[11:02] <stub> Although for questions, we can probably just do all the data migration in the db patch since it is much smaller.
[11:02] <stub> That will save the overhead of multiple db patches etc.
[11:02] <adeuring> ok, sound more conveniet :)
[11:07] <bigjools> wgrant: can you remember the exact reason for not using check_permission in model code?
[11:09] <wgrant> In this particular case I would forbid it anyway, since a user is taken explicitly. But check_permission is pretty terrible in model code in general because it's executed from scripts and other situations without a user context, so it's fairly meaningless.
[11:10] <bigjools> ah that was it
[11:50] <bigjools> I am moving an exported method from IDistroSeriesPublic to IDistroSeriesEditRestricted.  Unfortunately the copy_field directives in the @operation_paramters now refer to fields in the other class.  Is there a way to make it work or do I need to repeat the actual field declaration again?
[11:52] <wgrant> bigjools: You can't just refer to the other class?
[11:52] <wgrant> Or are they in the wrong order?
[11:55] <bigjools> wgrant: wrong order, but that's easily fixed
[11:56] <wgrant> Otherwise use one of the usual patchers.
[11:57] <bigjools> nope, doesn't work
[12:00] <wgrant> !doesn't work
[12:00] <wgrant> Bah, no ubottu
[12:01]  * bigjools scratches head
[12:01] <wgrant> 21:01:09 <ubottu> Doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be  specific! Examples of what doesn't work tend to help too.
[12:01]  * bigjools slaps wgrant with a large haddock
[12:02] <bigjools> I'm doing something so obviously wrong I can't see the wood for the trees.
[12:02] <jpds> Hmm, work from couch.
[12:02] <bigjools> I've got name=copy_field(IDistroSeriesPublic.name ....
[12:02] <spiv> bigjools: slapping people with Tintin characters is a bit extreme!
[12:02] <bigjools> which errors out with AttributeError: 'InterfaceClass' object has no attribute 'name'
[12:02] <wgrant> bigjools: Oh.
[12:02] <wgrant> IDistroSeriesPublic['name']?
[12:02] <bigjools> spiv: Python reference!
[12:03] <bigjools> wgrant: EUARGH
[12:03] <spiv> bigjools: a weakref :P
[12:04] <bigjools> spiv: not counted properly
[12:04] <wgrant> bigjools: An interface is not a class!
[12:04] <bigjools> yes it is
[12:04] <bigjools> it says "class" :)
[12:04] <henninge> gmb: Here is a nice little branch for you, if you'd be so nice to take it, please. ;-)
[12:04] <wgrant> That's just because Python sucks.
[12:04] <henninge> https://code.launchpad.net/~henninge/launchpad/bug-196679-language-packs-value-error/+merge/60487
[12:05] <bigjools> sometimes, yes it does
[12:05] <bigjools> and coming from a C++ background it confuses the shit out of me sometimes
[12:05] <gmb> henninge: Ah, the perfect size to review just before lunch.
[12:05] <henninge> gmb: great, thanks
[12:05] <spiv> bigjools: also, wikipedia, the source of all true and indisputible knowledge, says the fish-slapping dance involved pilchards and a halibut.
[12:06] <bigjools> I bow to wikipadeoia
[12:08] <gmb> henninge: r=me.
[12:08]  * gmb -> Vittles
[12:11] <wgrant> If there is something bad in r13009 or r13011, I am going to be very sad.
[12:13] <spiv> wgrant: Python's class statement doesn't suck, it's great.  It allows stuff like class Ten(1,2,3,4): __metaclass__ = type('', (type,), {'__new__': lambda *a: sum(a[2])})
[12:14] <spiv> How could that be a bad thing? ;)
[12:14] <wgrant> spiv: Did you pull that off the quotes page?
[12:14] <wgrant> I'm sure I've seen it there.
[12:14] <spiv> No, but it's probably due to me that a version of that is already there.
[12:15]  * bigjools vomits
[12:15] <wgrant> Indeed, https://wiki.canonical.com/Quotes/2005
[12:15] <wgrant> "Evil Python"
[12:15] <spiv> I think last time I made that remark I didn't condense it into a one-liner though!
[12:15] <henninge> gmb: thanks
[12:31] <LPCIBot> Project db-devel build #533: FAILURE in 5 hr 2 min: https://lpci.wedontsleep.org/job/db-devel/533/
[12:33] <wgrant> bigjools: I can talk DSPs for a while now if you still want, and the others are around.
[12:33] <bigjools> wgrant: sure
[12:35] <bigjools> -> mumble
[12:37] <bigjools> jtv, StevenK, are you free to mumble with wgrant and me for a little while?
[12:37] <jtv> coming
[12:38] <jtv> oh no not this problem again
[12:38] <bigjools> 'fraid so
[12:39] <danilos> gmb, hey-hey, I've got a review for you when you find some time :) https://code.launchpad.net/~danilo/launchpad/bug-771204/+merge/60493
[13:03] <gmb> danilos: I'll take a look at that now.
[13:04] <danilos> gmb, thanks
[13:13] <gmb> danilos: Looks good. r=me
[13:23] <danilos> gmb, ta (sorry, lunch :)
[13:25] <danilos> hum, is it just me or has all the ajax stuff stopped working on the MP page?
[13:25]  * danilos tries in firefox
[13:25] <wgrant> Worked for me a few hours ago.
[13:26] <danilos> works in firefox and chromium, a problem with bare webkit JS engine?
[13:30] <StevenK> bigjools: Sorry, I was dinner-ing.
[13:31] <bigjools> StevenK: np, we're just finishing :)
[13:32] <danilos> hum, false alarm: launchpad.js was misloaded, some garbage at the beginning — I suppose some of my hardware is acting up
[13:33] <StevenK> bigjools: Anything earth-shattering?
[13:33] <bigjools> haha, who did the tweet about jml's pie being meaty?
[13:33] <bigjools> StevenK: I'kk summarise in an  email
[13:33] <bigjools> I'll, even
[13:33] <StevenK> bigjools: Will I'kk help?
[13:37]  * henninge reloacates
[13:41]  * bigjools -> food
[13:58] <deryck> Morning, all.
[13:58] <rvba_> wgrant: (I just got back ...) thanks for taking care of the fix ;).
[14:00] <LPCIBot> Project windmill-devel build #59: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/59/
[14:01] <wgrant> rvba_: It all looks good. Sorry, I should have been more clear when I rolled it back the first time.
[14:02] <jtv> allenap: do you know what would be a simple way for a test to verify whether a package had been copied?
[14:02] <rvba_> wgrant: and I think I should have been more careful before modifying the callsites. Thanks anyway.
[14:03] <allenap> jtv: I think I know the answer to that...
[14:03] <allenap> jtv: See PackageCopyJobTests.test_smoke.
[14:03] <jtv> ah thanks!
[14:04] <allenap> jtv: The last 3 lines actually. It's quite simple.
[14:04] <jtv> Archive.getPublishedSources?
[14:04] <wgrant> I tend to check that getPublishedSources(name=whatever) returns nothing before, and one row after.
[14:26] <henninge> Do either staging or qastaing process incoming mail? i.e. MP discussions
[14:29] <mwhudson> henninge: they both do i think?
[14:29] <mwhudson> process-mail.py may not be run very often though
[14:31] <henninge> ok, I'll try it out once qastaging stops timing out on me ...
[14:31] <henninge> oh, it's not a timeout
[14:31] <wgrant> MPs don't work.
[14:31] <wgrant> Because they need restricted librarian access.
[14:31] <wgrant> You might want to create a new MP.
[14:32] <wgrant> MPs synced from production don't work, that is.
[14:33] <henninge> wgrant: I just got a LookupError for an LFA AFAICT. Is that what you mean?
[14:33] <wgrant> henninge: yes.
[14:33] <henninge> aha
[14:33] <wgrant> They try to look up the LFA in the staging librarian. That would normally forward to the production librarian, but that can't happen for restricted files.
[14:34] <henninge> how do I simulate mail processing locally?
[14:35] <wgrant> lib/canonical/launchpad/doc/mailbox.txt
[14:35] <wgrant> But I'd try creating a fresh MP on qastaging first.
[14:35] <henninge> wgrant: cheers
[14:35] <wgrant> It won't have a diff.
[14:35] <wgrant> but it will receive emails OK.
[14:35] <henninge> oh, ok
[14:35] <henninge> thanks
[14:36] <henninge> code update in progress ...
[14:43] <wgrant> henninge: Nice catch.
[14:43] <wgrant> henninge: I hadn't noticed that the . had wrapped in both cases.
[14:43] <henninge> ;-)
[14:43] <wgrant> It may still be a problem in the MTA stack in front of LP, but now we'll be able to find out :)
[14:44] <henninge> righit, that's what I figure.
[14:45] <henninge> wgrant: but I think that MTAs and MUAs watch for things like that and escape single dots.
[14:45] <henninge> just like "From"
[14:45] <wgrant> henninge: Yes, but our MTAs do all sorts of strange crap.
[14:45] <henninge> :(
[14:45] <henninge> ok, I'll see if I find something
[14:45] <wgrant> To add extra headers like X-Launchpad-Original-To
[14:48] <wgrant> Night all.
[14:48] <henninge> wgrant: night
[14:50] <mwhudson> oh ****, is that why mails to mps sometimes get truncated?  because they contain '\n.\n.?
[14:50] <henninge> mwhudson: yup
[14:50] <mwhudson> henninge: wow
[14:50] <henninge> mwhudson: although it looks like we create these by wrapping lines.
[14:51] <bigjools> ha, that's the SMTP end of data line
[14:52] <mwhudson> eeeeeeeeeeeeeeeeeeeeeeeeeee
[14:54] <mwhudson> that's just so messed up
[14:55] <mwhudson> so how does the wrapping happen?  presumably it must be before lp gets to see it, if smtp-level corruption is what's causing the problem
[14:56] <henninge> I don't know yet
[14:57] <mwhudson> good luck finding out :)
[15:06] <LPCIBot> Project windmill-db-devel build #258: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-db-devel/258/
[15:22] <bigjools> gmb: afternoon m'lad, I have a small branch for your perusal if you're still reviewing?
[15:23] <gmb> bigjools: Sure. Diff me.
[15:23] <bigjools> gmb: https://code.launchpad.net/~julian-edwards/launchpad/derive-permissions-bug-643369/+merge/60515
[15:23] <bigjools> cheers
[15:24]  * gmb looks
[15:25] <jml> wallyworld_: https://bugs.launchpad.net/launchpad/+bug/184737 is relevant to the thing you just said
[15:25] <_mup_> Bug #184737: No tag autocomplete in +filebug extra options <bugtag> <filebug> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/184737 >
[15:26] <jml> wallyworld_: about tag completion on bug subscription forms.
[15:26] <wallyworld_> jml: wow. that's an old bug :-)
[15:26] <jml> wallyworld_: yeppers.
[15:26] <jml> wallyworld_: classic case of a bug that's not too hard to fix, very useful, but no one getting around to it
[15:27] <bigjools> gmb: I wish diff generators could be more useful sometimes, the one on that MP looks like a dog's breakfast
[15:27] <wallyworld_> jml: i hear you. hopefully *this* particular one will now be fixed since it's tied to a feature sprint :-)
[15:28] <bigjools> hey wallyworld_ are you at UDS?
[15:28] <gmb> bigjools: It's okay, I'm used to it these days.
[15:28] <gmb> But yer not wrong
[15:28] <bigjools> gmb: it needs a "moved but not changed" marker
[15:28] <gmb> +1
[15:28] <wallyworld_> bigjools: yep :-)
[15:28] <bigjools> wallyworld_: will see you Thursday arvo then
[15:29] <wallyworld_> bigjools: sadly no. i'm leaving tomorrow :-(
[15:29] <bigjools> wallyworld_: ah bugger
[15:29] <wallyworld_> yep. bollocks all right
[15:30] <wallyworld_> bigjools: brad c is doing a session on the new bug subscription stuff. looks good
[15:30]  * gmb is listening in.
[15:30] <wallyworld_> hi gmb
[15:31] <gmb> Hey wallyworld_. Glad you like :)
[15:31] <wallyworld_> gmb: to quote borat - "niiiiiiice"
[15:31] <gmb> Indeed. You should ask sabdfl to do his Borat.
[15:32] <wallyworld_> gmb: so long as there's no mankini involved :-)
[15:32] <bigjools> I have the vid on my laptop....
[15:32]  * gmb goes to bleach his minds eye
[15:32] <wallyworld_> lol :-)
[15:33]  * StevenK has it here somewhere too
[15:33] <gmb> I'm guessing jml is sat near the mic, based on the typing and the deep sound of his voice.
[15:33] <jml> gmb: heh heh
[15:34] <jml> what's the bug for seeing all subscriptions across LP?
[15:34] <wallyworld_> don't know
[15:35] <bigjools> wallyworld_: which room?
[15:35] <gmb> jml: Looking now for you
[15:35] <wallyworld_> bigjools: krudy
[15:35] <wallyworld_> room 6
[15:35] <bigjools> ta
[15:35] <jml> gmb: thanks.
[15:35] <jml> also in topic of #launchpad
[15:36] <gmb> jml: https://bugs.launchpad.net/launchpad/+bug/110953 seems to be the one being referenced in the most recent thread about this.
[15:36] <_mup_> Bug #110953: Can't easily see everything I'm subscribed to <infrastructure> <lp-registry> <story-better-bug-notification> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/110953 >
[15:36] <jml> gmb: thanks.
[15:36] <bigjools> is everyone sat nowhere near the mics as usual? :)
[15:37] <jml> bigjools: bac, mordred & I
[15:37] <jml> bigjools: everyone else is in the back row.
[15:37] <bigjools> jml: figures
[15:37] <jml> bigjools: including flacoste
[15:37] <bigjools> !
[15:37] <wallyworld_> bigjools: so we can heckle easier :-)
[15:38] <gmb> If we didn't draw the line somewhere on this feature I was going to have to self-trepanate in order to make 8 months' worth of brain juice drain away.
[15:39] <StevenK> No definitions found for "trepanate"
[15:39] <gmb> StevenK: Try trepanation or Trepanning
[15:40] <StevenK> Oh, using a trepan on yourself
[15:40] <StevenK> Sounds gruesome. And hard to get right.
[15:43] <jelmer> is gmb using difficult words again ?
[15:43] <gmb> Be thankful I aten't prattling in Lanky.
[15:44] <jelmer> garr. now I really have to spend some quality time with my dictionary.
[15:45] <StevenK> jelmer: s/\(is gmb\) \(using difficult words\)/\1 still \2/
[15:45] <StevenK> Oh bah, that won't drop the again. Oh well
[15:45] <bigjools> spectacular backfire
[15:46] <gmb> bdmurray: No, that doesn't work right now, but there probably should be some way to do it - we just haven't figured it out yet. I don't think there's a bug for it though.
[15:46] <StevenK> It's nearly 1am, and I'm trying to fix Jenkins
[15:48] <StevenK> Right, new build slave finally started
[15:50] <wallyworld_> jml: you still have etherpad open?
[15:50] <jml> wallyworld_: yes.
[15:50] <wallyworld_> jmL: 780568
[15:50] <jml> wallyworld_: thanks
[15:54] <NCommander> Is there a way to determine why a PPA upload is dropping into the void?
[15:54] <bigjools> NCommander: https://answers.edge.launchpad.net/launchpad/+faq/227
[16:03] <adeuring> cody-somerville: could you please try to access https://qastaging.launchpad.net/%7Ereprepro/+archivesubscriptions ? the timeout should be gone there -- but I can't test it myself -- permission denied
[16:07] <cody-somerville> adeuring, qastaging doesn't have enough subscriptions to cause it
[16:08] <adeuring> cody-somerville: really? It should use the same DB as the production server
[16:09] <cody-somerville> adeuring, really
[16:09] <cody-somerville> :(
[16:09]  * cody-somerville is in a session, can chat more about this later.
[16:13] <LPCIBot> Project db-devel build #534: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/db-devel/534/
[16:32] <abentley> deryck: Am I high on context managers? http://pastebin.ubuntu.com/605743/
[16:32] <benji> gmb: I have a small branch ready for review (no particular rush): https://code.launchpad.net/~benji/launchpad/bug-778689/+merge/60520
[16:33] <deryck> abentley, looking....
[16:34] <gmb> benji: I'll take a look shortly
[16:35] <deryck> abentley, high as in too many?  Or high as in floating wild and free in the joy that is context managers? :-)
[16:37] <deryck> abentley, I like the code, though.  nice approach to the problem.
[16:37] <abentley> deryck: Well, really, is there a better way to do this?
[16:37] <deryck> abentley, I can't think of one.  I think this is spot on.
[16:37] <abentley> deryck: Okay, cool.
[16:40] <gmb> bigjools: Your branch is r=me. Has been for ages but I got distracted by the UDS session.
[16:40] <bigjools> gmb: ok ta :)
[16:41] <gmb> benji: Your test needs a comment stating what it's testing for so that lazy gits like me don't have to go and look up the bug report.
[16:41] <gmb> Other than that, r=me.
[16:42] <benji> gmb: heh, will do
[16:42] <sinzui> jcsackett: mumble?
[16:43] <gmb> And that's quite enough of that for today.
[17:19] <NCommander> are there known issues with LP on natty? postgresql is puking when I try to make schema
[17:27] <jcsackett> sinzui: when you're available, https://code.launchpad.net/~jcsackett/launchpad/spam-button-ui-bugs/+merge/60437
[17:27] <jcsackett> i assume the one you need is https://code.launchpad.net/~sinzui/launchpad/person-merge-oopses-0/+merge/60521 ?
[17:27] <sinzui> jcsackett: I will start it now, and yes
[17:28] <jcsackett> cool. i will start yours momentarily.
[17:43] <sinzui> I may be disappointed when developers stop cargo culting my "// Lock, stock, and two smoking barrels." comment
[17:46] <jcsackett> :-)
[17:46] <jcsackett> it's a fantastic way to wrap up a test.
[17:46] <sinzui> It is one of my favourite films
[17:49] <jcsackett> it is pretty fantastic.
[17:52] <jcsackett> i clearly do not actually understand IStore/storm stores. I would have thought that creating a store of IPerson would only let you get person objects.
[18:00] <jcsackett> sinzui: r=me. as i mention in the comment, there may be some value to moving the reload utilities to something accessible for other tests as it could be handy, but the argument of YAGNI may very well apply.
[18:02] <sinzui> jcsackett: I will move it into lp.testing
[18:04] <jcsackett> sinzui: cool. :-)
[18:10] <mrevell> Night!
[18:56] <jcsackett> sinzui: thanks for the notes, i'll make those changes.
[18:56] <jcsackett> though i may do the test changes as part of my tech-debt branch.
[19:04] <LPCIBot> Project windmill-devel build #60: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/60/
[19:05]  * deryck looks around the room for yellow squad....
[19:06] <deryck> benji or gmb maybe?  I have fixed a critical js bug related to the subscriptions story.
[19:06] <deryck> maybe one of you would want to review it?
[19:06] <benji> deryck: sure
[19:07] <deryck> benji, thanks!  https://code.launchpad.net/~deryck/launchpad/dupe-unsub-no-remove-name-775335/+merge/60538
[19:12] <benji> deryck: looks good
[19:12] <deryck> benji, thanks!
[19:12] <benji> np
[19:15] <LPCIBot> Project windmill-db-devel build #259: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-db-devel/259/
[19:25] <deryck> mbarnett, hey.  any time to look at that disappearing merge yet?
[19:40] <abentley> deryck: To determine the correct timeout for branch upgrades, I decided to look at the logs.
[19:41] <deryck> abentley, ah, cool.  what did you end up with then?
[19:41] <abentley> deryck: These are the durations I was able to find: http://pastebin.ubuntu.com/605825/
[19:41]  * deryck looks
[19:42] <abentley> deryck: It doesn't feel like there's really enough data to have a good guess.
[19:42] <deryck> abentley, yeah.  based on that, most everything finishes in under 10 minutes, right?
[19:42] <abentley> deryck: No, many things are +30
[19:43] <deryck> abentley, is it:  HH:MM:SS ?
[19:43] <deryck> the log format?
[19:44] <abentley> Yes, it's HH:MM:SS.
[19:45] <abentley> I think the ~0 second durations don't count.  They're prolly cases where the upgrade was already performed.
[19:45] <deryck> abentley, so I see 36 lines, with 8 items > 10 minutes.  so roughly 20%.
[19:45] <deryck> ah
[19:46] <deryck> so somewhere around 8/18.  closer to 50% over 10 minutes.
[19:46] <deryck> abentley, yeah, that's a hard call what to set then.
[19:47] <abentley> deryck: On the plus side, we can't be wasting a lot of resources if upgrades are this rare.
[19:47] <deryck> true
[19:48] <deryck> abentley, maybe we don't need the timeout then?  Or else a high number, i.e. 1 or 2 hour cap?
[19:48] <abentley> Yes, I think we need a timeout for outliers, but 1 hour seems reasonable.
[19:49] <deryck> abentley, cool. agreed.
[19:50] <abentley> deryck: thanks.
[19:50] <deryck> np!
[19:52] <sinzui> jcsackett:  can you put some thoughts about the effort needed to hide merge comments in the UI: https://bugs.launchpad.net/launchpad/+bug/697495
[19:52] <_mup_> Bug #697495: need SQL to hide/edit comments from merge proposals <canonical-losa-lp> <code-review> <comments> <Launchpad itself:Triaged> < https://launchpad.net/bugs/697495 >
[19:55] <sinzui> jcsackett: I can see that ICodeReviewComment is exported, we may only need to add the setVisibility() method and extend the js to work with the page
[19:59] <LPCIBot> Project windmill-db-devel build #260: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-db-devel/260/
[20:04] <jkakar> FYI, a bug that appeared randomly a few days ago is preventing us (Fluidinfo) from seeing milestone views. :(
[20:04] <jkakar> A sample OOPS: OOPS-1956CO39
[20:04] <jkakar> Should I file a bug about this or is the presence of the OOPS enough that someone will get around to looking at it?
[20:09] <jcsackett> sinzui: i believe you are correct. since the interface is already exported, we should only need to copycat the setCommentVisibility + js work.
[20:10] <jcsackett> i have just discovered there is a comment.js thing as well; i may explore putting the hide-comment code in there and then we can extend to each comment type.
[20:10] <sinzui> jcsackett: I am tempted to commit to this if we could land it by Monday
[20:11] <jcsackett> sinzui: i think monday is possible.
[20:11] <jcsackett> did you just come across this bug, or has it come up as a problem recently?
[20:11] <sinzui> It is a bug linked to a question we cannot resolve
[20:11] <jcsackett> ah.
[20:12] <jcsackett> so, let me finish my tech-debt branch, and i'll commit to 4 hours to explore MP comments?
[20:12] <deryck> jkakar, hi.  I would recommend filing the bug to be safe.
[20:12] <jcsackett> if i don't have a good feeling of scope at the end of that (which will probably be tomorrow) we won't commit to doing the work?
[20:13] <jcsackett> sinzui ^
[20:13] <jkakar> deryck: Awesome, I'll do that, thanks!
[20:15] <sinzui> jcsackett: I want to be sure that we are not getting bug reports when we switch to features. I image we want to be able to land a branch to fix any issued after Monday. I
[20:26] <jcsackett> sinzui: next week is theoretically our last week before switching, or week after next?
[20:27] <sinzui> We are in our last two weeks of maintenance.
[20:34] <jcsackett> ok.
[20:39] <lifeless> benji: hi
[20:39] <benji> hi
[20:39] <lifeless> https://bugs.launchpad.net/launchpad/+780703
[20:40] <lifeless> benji: I *think* thats a better-notification-regression
[20:40] <lifeless> benji: its definitely a regression, the regressor is what I'm unsure of
[20:41] <lifeless> benji: (they are a paying customer FWIW, but I suspect its much more widespread)
[20:41] <benji> it's tangentially related to the better-notification story; I'm working on it as we speak
[20:42] <lifeless> oh cool - you were already looking at the regression ?
[20:42] <benji> more specifically, it's working it's way through ec2 as we sppeak
[20:42] <lifeless> wowsers, even better
[20:42] <benji> yep, there is another bug; let me find it
[20:43] <benji> here it is: https://bugs.launchpad.net/launchpad/+bug/778689
[20:43] <_mup_> Bug #778689: ProjectMilestone:+global-actions: oops rendering the structural subscription link <oops> <story-better-bug-notification> <Launchpad itself:In Progress by benji> < https://launchpad.net/bugs/778689 >
[20:44] <lifeless> thanks!
[20:44] <benji> I'll mark the new one a duplicate of the one I was working on
[20:45] <lifeless> I've just done that
[20:46] <benji> cool
[21:00] <lifeless> deryck: ready when you are
[21:00] <deryck> lifeless: ok, firing up skype now
[21:01] <deryck> lifeless: call when you're ready
[21:05] <LPCIBot> Project windmill-devel build #61: STILL FAILING in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill-devel/61/
[21:36] <benji> sinzui: do you have a minut to do a teeny, tiny JS review? (of a branch that fixes a bug that you reported (notifications close if you click on a link inside them))
[21:37] <sinzui> I can do it now
[21:38] <benji> sinzui: great! https://code.launchpad.net/~benji/launchpad/bug-779538/+merge/60552
[21:40] <sinzui> benji: I select text in the notifications sometimes.I think the function will never let me copy the text to report a bug
[21:41] <benji> hmm, good one; let me look at it real quick
[21:42] <benji> sinzui: yep, that's a problem; back to the drawing board
[21:42] <benji> I may well revert the feature if I can't figure something sane out quickly.
[21:42] <sinzui> benji: can the action be wired to a the links id?
[21:42] <sinzui> We know the text of the link is Hide x
[21:43] <benji> well, that's not really a link; that's style; there's no element there
[21:43] <sinzui> ah, right
[21:43] <sinzui> I see your point about reverting.
[21:49] <LPCIBot> Project windmill-devel build #62: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-devel/62/
[22:07] <jcsackett> sinzui: if you had very similar testcases in questions and bugs, and were creating a base class for them to share, where would you put that class? lp.testing doesn't feel right, since the base test case won't be *that* generally useable.
[22:08] <sinzui> jcsackett: lp/coop/bugquestion
[22:08] <jcsackett> excuse the muddy thinking; a shared mixin is what i'm talking about.
[22:08] <jcsackett> sinzui: thanks!
[22:09] <james_w> benji, could you add the hide link with js? That would allow you to create an actual element with a onClick behaviour?
[22:10] <sinzui> jcsackett: lib/lp/coop/answersbugs/ actually. but may lib/lp/coop/comments if we add merge proposals
[22:10] <benji> james_w: I'm trying to avoid that because I want on-page JS to be able to add message boxes after page load time
[22:10] <jcsackett> sinzui: i like lib/lp/coop/comments, since some day we want that all to be shared properly.
[22:10] <james_w> benji, ah, ok
[22:11] <benji> the only way I can think of doing that right now is useing setInterval, but that feels a bit gross
[22:16] <lifeless> jcsackett: I would avoid creating a base class :)
[22:16] <lifeless> jcsackett: what does the code you want to share do
[22:16] <jcsackett> lifeless: base class was the wrong statement. mixin is what i'm looking at.
[22:17] <lifeless> jcsackett: same dealio
[22:17] <jcsackett> i have *very* similar tests that deal with question messages and bug comments. i would like to not have repeating code.
[22:17] <lifeless> jcsackett: indeed!
[22:18] <jcsackett> lifeless: so, a mixin that provides those shared things seemed like a good idea to me. what's the argument against?
[22:18] <lifeless> http://rbtcollins.wordpress.com/2010/09/18/maintainable-pyunit-test-suites-fixtures/ and http://rbtcollins.wordpress.com/2010/05/10/maintainable-pyunit-test-suites/ may interest you
[22:18] <lifeless> jcsackett: what are the shared things
[22:19] <jcsackett> lifeless: aside from slight diffs in setup and the context being thrown at a test browser, the tests are looking at the same series of things.
[22:19] <lifeless> jcsackett: ah, so you want to test their adherence to the contract?
[22:19] <lifeless> pypi.python.org/pypi/testscenarios for that :>
[22:20] <lifeless> jcsackett: a mixin is fine, but its not all that maintainable
[22:20] <lifeless> jcsackett: you don't need to do anything different, I'm just gathering data about the things we do and why
[22:24] <jcsackett> lifeless: well, if what i'm doing is going to perpetuate problems we have, i'd rather not.
[22:24] <jcsackett> i'll take a look at testscenarios. i may have descibed my issue wrong.
[22:24] <lifeless> jcsackett: cool
[22:24] <jcsackett> in essense both cases have "test_thing_one", "test_other_thing", "test_thing_one_with_edge_case"
[22:25] <lifeless> so, I *love* test-by-contract
[22:25]  * jcsackett is not really sure what is meant by that.
[22:25] <lifeless> uhm
[22:25] <lifeless> testing that two objects that implement interface I obey the behaviour of the interface
[22:26] <lifeless> so bugmessage and questionmessage are two classes that need the same behaviour
[22:26] <lifeless> I wrote http://people.canonical.com/~robertc/interfaceverification.txt back in 2005 about doing this for persistence layers :)
[22:27] <jcsackett> ah, okay.
[22:28] <lifeless> jcsackett: anyhow it seems to me that you have some common do-stuff code, a different factory (or fixture) for each class and perhaps variant 'did it do the right thing' for each class
[22:28] <lifeless> I haven't integrated testscenarios into launchpad yet, but using a per-file test_suite hook should let it integrate pretty easily on a case-by-case basis.
[22:29] <lifeless> I would be inclined to structure these tests as fixtures for the bugmessage/questionmessage construction, matchers for the things to check and a single test class in the message area which is parameterised by the fixtures and matchers
[22:29] <lifeless> *but*
[22:30] <lifeless> this is sucking away your activation energy bringing in different ways of doing stuff
[22:30] <lifeless> so I really do think its fine to do a mixin
[22:30] <lifeless> like I said, I meant just to do data gathering
[22:31] <jcsackett> matchers are something i am using, per a suggestion you had on an earlier branch.
[22:31] <lifeless> yeah, they are pretty cool :)
[22:31] <lifeless> and already integrated in
[22:31] <lifeless> fixtures are already integrated in too
[22:32] <jcsackett> yeah, i used matchers on some snapshotting work.
[22:32] <deryck> Later on, everyone.
[22:44] <LPCIBot> Project windmill-db-devel build #261: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-db-devel/261/
[23:58] <wgrant> sinzui: Hi.
[23:58] <sinzui> hello
[23:58] <wgrant> sinzui: Can you QA your answer contact API stuff?
[23:58] <sinzui> I can
[23:59] <wgrant> It looks like we may finally not have any bad revs.
[23:59] <lifeless> statik: yo