[00:01] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/demolish-bvp/+merge/128610
[00:04] <StevenK> wgrant: lib/lp/code/browser/tests/test_branch.py the lp.code.enums import should be shrunk
[00:04] <wgrant> Ah, and there were two ordering issues that appear to not have been my fault
[00:05] <wgrant> But those were the only format-imports complaints
[00:05] <wgrant> And they are now fixed
[00:06] <StevenK> wgrant: I don't think you need the _is_private_team helper
[00:06] <StevenK> People are implicity public, so if self.private: should be fine
[00:07] <wgrant> We usually check both
[00:10] <StevenK> wgrant: Looks great.
[00:14] <wgrant> Thanks
[04:48] <wgrant> Oh good
[04:49] <wgrant> My new terrible version of retry-depwait is 30% faster than the old one
[04:49] <wgrant> Despite my version considering several times more builds than it needs
[04:49] <StevenK> How is still terrible?
[04:49] <wgrant> It does just about no filtering in the core looptuner query
[04:50] <wgrant> So it doesn't exclude obsolete series etc. until inside the main loop
[04:50] <StevenK> Hah
[04:50] <StevenK> That should be easy to be fix
[04:50] <StevenK> But this is Soyuz
[04:57] <bigjools> that old code is older than wgrant
[04:58] <StevenK> Just about
[04:58] <StevenK> wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/sanity-check-bugwatch-bug-id/+merge/128625
[05:41] <wallyworld__> StevenK: can has comment inthe test as to what consistutes a valid/invalid bug number?
[05:42] <wallyworld__> maybe it's clear, but not from just looking at the diff
[05:42] <wallyworld__> s/bug number/bug url perhaps
[05:44] <StevenK> wallyworld__: http://pastebin.ubuntu.com/1268760/
[05:45] <wallyworld__> cool. thanks
[05:45] <wallyworld__> r=me
[05:45] <StevenK> wallyworld__: Thanks
[05:45] <wallyworld__> np
[05:46] <StevenK> wallyworld__: I was expecting a query about the usage of re.sub, TBH :-)
[05:46] <wallyworld__> why? seems ok to me
[05:49] <StevenK> wallyworld__: "Why are you doing it that way, that's terrible" etc :-)
[05:49] <wallyworld__> well, it's concise and it works, so meh
[05:49] <wallyworld__> and there's a comment in the test
[07:47] <adeuring> good morning
[08:48] <wgrant> Test results: demolish-bvp => devel: SUCCESS
[08:48] <wgrant> yay
[08:51] <StevenK> After how many hours?
[08:52] <wgrant> This was the third run today
[08:52] <wgrant> Added sampledata... broke tests that depended on IDs of new stuff
[08:53] <StevenK> Hah
[08:53] <StevenK> I just merged devel into mine, that was horrible
[10:13] <dpm> hi all, who can edit the VCS source for vcs-imports? I was looking at why translations weren't being imported from upstream's e-d-s and it seems it's because the VCS import is still set to SVN instead of git - could someone help me with editing the upstream source branch on https://code.launchpad.net/~vcs-imports/evolution-data-server/trunk ?
[10:17] <maxb> dpm: Members of ~vcs-imports - what would you like changed?
[10:17] <wgrant> dpm: You'll need to create a new import if the VCS has changed
[10:18] <maxb> Indeed - shall I rename the old one out of the way?
[10:19] <dpm> maxb, if you could do that, that'd be great, thanks!
[10:20] <maxb> Renamed to old-svn-trunk and set to 'Merged' status so that it doesn't show up in the default branch listings
[10:20] <maxb> Go ahead and create a new import
[10:24] <dpm> maxb, hm, how do I actually create a new import (I'm not a member of ~vcs-imports)?
[10:25] <cjwatson> dpm: https://help.launchpad.net/VcsImports
[10:26] <dpm> thanks cjwatson
[10:26] <maxb> https://code.launchpad.net/evolution-data-server , "Import a branch"
[10:30] <maxb> dpm: Under the new system of vcs import creation, the branch owner will be you or a team you are a member of if you select it - if you want the new import back at lp:~vcs-imports/evolution-data-server/trunk for consistency, let me know when you've created it and I'll move it over.
[10:34] <dpm> maxb, https://code.launchpad.net/~dpm/evolution-data-server/trunk - if you could move it over to ~vcs-imports, that'd be great
[10:35] <maxb> done
[10:39] <dpm> thanks maxb
[11:53] <cjwatson> Is there any pattern in Launchpad for a Job type that allows newly-created jobs to preempt existing ones in the middle of a long run of many jobs?
[11:54] <cjwatson> The usual iterReady implementations seem to compute the whole list of ready jobs up-front, which won't allow preemption.
[11:55] <cjwatson> I could turn the relevant iterReady implementation into a generator and have it suck jobs out of the DB in batches or something, but it seems a bit ad-hoc and I was wondering if there was anything pre-existing for this
[11:58] <wgrant> cjwatson: I know of nothing like that already
[12:03] <cjwatson> wgrant: OK, thanks :-/
[12:04] <cjwatson> Would it be ridiculously OTT to glue in a looptuner?
[12:05] <wgrant> I don't think a looptuner's too useful or feasible there
[12:06] <cjwatson> Why infeasible?
[12:06] <cjwatson> Doesn't really know the operation times, I suppose
[12:06] <wgrant> Right, and particularly with rabbitmq, it's reasonably important that if a job gets aborted then only that job gets aborted
[12:06] <wgrant> What benefit would a looptuner provide?
[12:06] <cjwatson> Not having to pick a hardcoded chunk size
[12:08] <wgrant> The operations will frequently fail. I'm not sure they can be sensibly batched like that.
[12:08] <cjwatson> They're already batched ...
[12:08] <cjwatson> process-job-source (eventually) calls iterReady, gets a list of however many ready jobs there are back
[12:09] <cjwatson> All at once
[12:09] <cjwatson> So, OK, not so much batched as one giant batch
[12:10] <cjwatson> But failure is handled at the level of individual jobs anyway
[12:10] <cjwatson> It doesn't propagate out to the level of whatever calls iterReady
[12:11] <wgrant> Right, it doesn'
[12:11] <wgrant> t chunk AFAIK
[12:11] <wgrant> So no point to a looptuner
[12:11] <wgrant> We usually use a looptuner to get small transaction lengths without committing 1000x more often than necessary
[12:12] <cjwatson> It doesn't chunk at the moment, but in order to allow preemption in the middle of a few thousand jobs that arrived all at once, it needs to
[12:13] <cjwatson> Or at least I don't see how to do that otherwise
[12:18] <wgrant> Is there likely to be a significant performance issue if you were to simply query for the head of the queue each time a job was needed?
[12:18] <wgrant> I'm not sure how terrible these queries tend to be
[12:27] <cjwatson> wgrant: Not too sure how I would tell.  All I can divine from logs is that it's usually sub-second
[13:19] <tumbleweed> frankban: care for an easy one? https://code.launchpad.net/~stefanor/launchpad/retry-cancelled-build/+merge/128683
[13:20] <frankban> tumbleweed: sure
[14:03] <tumbleweed> frankban: thanks. Would you mind landing it for me?
[14:06] <frankban> tumbleweed: yes, in a minute
[14:24] <frankban> tumbleweed: done
[14:25] <tumbleweed> frankban: thanks again
[17:17] <sinzui> jcsackett, what bug are you looking at now?
[17:18] <jcsackett> sinzui: i'm exploring bug 994561 and bug 1007124 as they seem related. was reading through the code and going to ping you for thoughts in a few.
[17:18] <_mup_> Bug #994561: IndexError: string index out of range <dkim> <email> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/994561 >
[17:18] <_mup_> Bug #1007124: Incorrect padding <dkim> <email> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1007124 >
[17:18] <jcsackett> happy to chat now though if you're free.
[17:19] <sinzui> okay
[19:39] <tumbleweed> to QA bug 1016337, I'd need a working PPA builder on a staging environment. Should I just not bother to QA it?
[19:39] <abentley> rick_h_: Could you please review https://code.launchpad.net/~abentley/launchpad/private-product-listings/+merge/128800 ?
[19:43] <rick_h_> abentley: sure thing
[19:44] <rick_h_> abentley: are the conflicts listed anything to worry about?
[19:45] <abentley> rick_h_: I don't think so.
[19:48] <abentley> rick_h_: Okay, yeah, there's a problem-- I've modified code that's been deleted, and DB columns I've used have been renamed.
[19:49] <rick_h_> abentley: so _information_type is getting renamed back in my branch I sent to ec2 land this morning
[19:49] <abentley> rick_h_: Okay, this is because of the rollback.
[19:49] <rick_h_> abentley: right
[19:50] <rick_h_> but yea, should we hold on this until abel finishes his update then?
[19:54] <abentley> rick_h_: Yeah.  I'd normally mark his branch as a prerequisite, but it's not clear what his work-in-progress branch is.
[19:55] <rick_h_> abentley: ok, we'll catch up in the morning and I can look it over then.
[21:37]  * StevenK stabs OOPS pruning.
[21:37] <StevenK> Clearly, I need to take a copy of the OOPS file to have any hope of reading them after linking them to a bug.
[21:38] <lifeless> StevenK: recent or old ?
[21:38] <StevenK> lifeless: https://bugs.launchpad.net/launchpad/+bug/956339 comment 1
[21:38] <_mup_> Bug #956339:   IntegrityError: new row for relation "codeimport" violates check constraint "valid_vcs_details"  <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/956339 >
[21:38] <lifeless> StevenK: so old
[21:41] <StevenK> lifeless: Given neem has OOPSes back to 2012-06-12, I don't buy it.
[21:42] <lifeless> StevenK: we had that bug which wgrant fixed recently
[21:43] <lifeless> StevenK: where we were only keeping references made w/in the first 24 hours
[21:44] <StevenK> Mmmm, I've been trying to recall how long the fix has been on neem.
[21:45] <wgrant> I think there may be another pruning bug
[21:45] <wgrant> But it's not quite so bad, I don't think
[21:45] <wgrant> And I don't know what it is yet
[21:46] <wgrant> StevenK: When you run into a case from the last month or so, let me know and I will fix it.
[21:46] <StevenK> wgrant: Does the 24th of November count? :-)
[21:46] <StevenK> Er, September
[21:46] <wgrant> Yes
[21:47] <StevenK> wgrant: bug 956339 comment 1
[21:47] <_mup_> Bug #956339:   IntegrityError: new row for relation "codeimport" violates check constraint "valid_vcs_details"  <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/956339 >
[21:47] <wgrant> Thanks.
[21:48] <lifeless> did we have it deployed then? I thought it was a couple days later ;)
[21:49] <wgrant> Oh
[21:49] <wgrant> It was Sep 24 itself
[21:49] <wgrant> Interesting timing :)
[21:50] <StevenK> Yeah, great. It's pruned the one OOPS again.
[21:50] <wgrant> Well, should be pretty easy to work out
[21:50] <wgrant> Find things that create codeimports
[21:51] <wgrant> Look at DB constraint
[21:51] <wgrant> See how those codepaths could violate the DB constraint
[21:51] <StevenK> I did, on the day I linked that OOPS.
[21:51] <StevenK> It looked pretty sane to me.
[22:00] <wgrant> StevenK: It may be useful to note that the most recent OOPS was not in fact from +new-import, but from +setbranch
[22:04] <wallyworld_> sinzui: StevenK: wgrant: jcsackett: mumble keeps hanging for me again, will keep trying
[23:47] <StevenK> No OOPS mentioning ArchiveSubscriptionError either :-(
[23:53] <StevenK> wgrant: So I think what is probably happening is the valid_absolute_url call in the CHECK CONSTRAINT is failing, but I have no proof