[00:01] StevenK: https://code.launchpad.net/~wgrant/launchpad/demolish-bvp/+merge/128610 [00:04] wgrant: lib/lp/code/browser/tests/test_branch.py the lp.code.enums import should be shrunk [00:04] Ah, and there were two ordering issues that appear to not have been my fault [00:05] But those were the only format-imports complaints [00:05] And they are now fixed [00:06] wgrant: I don't think you need the _is_private_team helper [00:06] People are implicity public, so if self.private: should be fine [00:07] We usually check both [00:10] wgrant: Looks great. [00:14] Thanks === matsubara is now known as matsubara-afk === _mup__ is now known as _mup_ [04:48] Oh good [04:49] My new terrible version of retry-depwait is 30% faster than the old one [04:49] Despite my version considering several times more builds than it needs [04:49] How is still terrible? [04:49] It does just about no filtering in the core looptuner query [04:50] So it doesn't exclude obsolete series etc. until inside the main loop [04:50] Hah [04:50] That should be easy to be fix [04:50] But this is Soyuz [04:57] that old code is older than wgrant [04:58] Just about [04:58] wallyworld__, wgrant: https://code.launchpad.net/~stevenk/launchpad/sanity-check-bugwatch-bug-id/+merge/128625 [05:41] StevenK: can has comment inthe test as to what consistutes a valid/invalid bug number? [05:42] maybe it's clear, but not from just looking at the diff [05:42] s/bug number/bug url perhaps [05:44] wallyworld__: http://pastebin.ubuntu.com/1268760/ [05:45] cool. thanks [05:45] r=me [05:45] wallyworld__: Thanks [05:45] np [05:46] wallyworld__: I was expecting a query about the usage of re.sub, TBH :-) [05:46] why? seems ok to me [05:49] wallyworld__: "Why are you doing it that way, that's terrible" etc :-) [05:49] well, it's concise and it works, so meh [05:49] and there's a comment in the test [07:47] good morning [08:48] Test results: demolish-bvp => devel: SUCCESS [08:48] yay [08:51] After how many hours? [08:52] This was the third run today [08:52] Added sampledata... broke tests that depended on IDs of new stuff [08:53] Hah [08:53] I just merged devel into mine, that was horrible [10:13] 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] dpm: Members of ~vcs-imports - what would you like changed? [10:17] dpm: You'll need to create a new import if the VCS has changed [10:18] Indeed - shall I rename the old one out of the way? [10:19] maxb, if you could do that, that'd be great, thanks! [10:20] Renamed to old-svn-trunk and set to 'Merged' status so that it doesn't show up in the default branch listings [10:20] Go ahead and create a new import [10:24] maxb, hm, how do I actually create a new import (I'm not a member of ~vcs-imports)? [10:25] dpm: https://help.launchpad.net/VcsImports [10:26] thanks cjwatson [10:26] https://code.launchpad.net/evolution-data-server , "Import a branch" [10:30] 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] 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] done [10:39] thanks maxb [11:53] 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] The usual iterReady implementations seem to compute the whole list of ready jobs up-front, which won't allow preemption. [11:55] 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] cjwatson: I know of nothing like that already [12:03] wgrant: OK, thanks :-/ [12:04] Would it be ridiculously OTT to glue in a looptuner? [12:05] I don't think a looptuner's too useful or feasible there [12:06] Why infeasible? [12:06] Doesn't really know the operation times, I suppose [12:06] Right, and particularly with rabbitmq, it's reasonably important that if a job gets aborted then only that job gets aborted [12:06] What benefit would a looptuner provide? [12:06] Not having to pick a hardcoded chunk size [12:08] The operations will frequently fail. I'm not sure they can be sensibly batched like that. [12:08] They're already batched ... [12:08] process-job-source (eventually) calls iterReady, gets a list of however many ready jobs there are back [12:09] All at once [12:09] So, OK, not so much batched as one giant batch [12:10] But failure is handled at the level of individual jobs anyway [12:10] It doesn't propagate out to the level of whatever calls iterReady [12:11] Right, it doesn' [12:11] t chunk AFAIK [12:11] So no point to a looptuner [12:11] We usually use a looptuner to get small transaction lengths without committing 1000x more often than necessary [12:12] 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] Or at least I don't see how to do that otherwise [12:18] 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] I'm not sure how terrible these queries tend to be === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: ~280 [12:27] wgrant: Not too sure how I would tell. All I can divine from logs is that it's usually sub-second [13:19] frankban: care for an easy one? https://code.launchpad.net/~stefanor/launchpad/retry-cancelled-build/+merge/128683 [13:20] tumbleweed: sure === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban, rick_h | Firefighting: - | Critical bugs: ~280 [14:03] frankban: thanks. Would you mind landing it for me? [14:06] tumbleweed: yes, in a minute [14:24] tumbleweed: done [14:25] frankban: thanks again === frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: ~280 [17:17] jcsackett, what bug are you looking at now? [17:18] 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 < https://launchpad.net/bugs/994561 > [17:18] <_mup_> Bug #1007124: Incorrect padding < https://launchpad.net/bugs/1007124 > [17:18] happy to chat now though if you're free. [17:19] okay === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === slank` is now known as slank [19:39] 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] rick_h_: Could you please review https://code.launchpad.net/~abentley/launchpad/private-product-listings/+merge/128800 ? [19:43] abentley: sure thing [19:44] abentley: are the conflicts listed anything to worry about? [19:45] rick_h_: I don't think so. [19:48] 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] abentley: so _information_type is getting renamed back in my branch I sent to ec2 land this morning [19:49] rick_h_: Okay, this is because of the rollback. [19:49] abentley: right [19:50] but yea, should we hold on this until abel finishes his update then? [19:54] 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] abentley: ok, we'll catch up in the morning and I can look it over then. === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: ~280 === ccxCZ_ is now known as ccxCZ [21:37] * StevenK stabs OOPS pruning. [21:37] 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] StevenK: recent or old ? [21:38] 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" < https://launchpad.net/bugs/956339 > [21:38] StevenK: so old [21:41] lifeless: Given neem has OOPSes back to 2012-06-12, I don't buy it. [21:42] StevenK: we had that bug which wgrant fixed recently [21:43] StevenK: where we were only keeping references made w/in the first 24 hours [21:44] Mmmm, I've been trying to recall how long the fix has been on neem. [21:45] I think there may be another pruning bug [21:45] But it's not quite so bad, I don't think [21:45] And I don't know what it is yet [21:46] StevenK: When you run into a case from the last month or so, let me know and I will fix it. [21:46] wgrant: Does the 24th of November count? :-) [21:46] Er, September [21:46] Yes [21:47] wgrant: bug 956339 comment 1 [21:47] <_mup_> Bug #956339: IntegrityError: new row for relation "codeimport" violates check constraint "valid_vcs_details" < https://launchpad.net/bugs/956339 > [21:47] Thanks. [21:48] did we have it deployed then? I thought it was a couple days later ;) [21:49] Oh [21:49] It was Sep 24 itself [21:49] Interesting timing :) [21:50] Yeah, great. It's pruned the one OOPS again. [21:50] Well, should be pretty easy to work out [21:50] Find things that create codeimports [21:51] Look at DB constraint [21:51] See how those codepaths could violate the DB constraint [21:51] I did, on the day I linked that OOPS. [21:51] It looked pretty sane to me. [22:00] StevenK: It may be useful to note that the most recent OOPS was not in fact from +new-import, but from +setbranch [22:04] sinzui: StevenK: wgrant: jcsackett: mumble keeps hanging for me again, will keep trying === matsubara is now known as matsubara-afk [23:47] No OOPS mentioning ArchiveSubscriptionError either :-( [23:53] 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