[03:09] wgrant: Hmm, I thought we already had a script to clean up failed translations imports? Ref bug 576822 [03:09] <_mup_> Bug #576822: Add an option to clean up after a failed run of copy-translations-from-parent.py

< https://launchpad.net/bugs/576822 > [03:12] StevenK: I think there was a one-off script for precise [03:34] 450282.22s OOPS-674539797ca55814a0c0894007b34498 Unknown [03:34] BLINK [03:35] 5 days, 5 hours [03:35] thats some request [03:36] oooooh [03:36] checkwatches unhung [03:36] That explains a lot of the other OOPSes [03:37] Right [03:37] I just loaded that OOPS [03:37] So [03:37] Next step [03:38] Work out what bugwatch 57103 is [03:38] bugzilla.filesystems.org #632 [03:39] The host responds, but doesn't look much like a bugzilla at all really [03:39] honeypot? [03:39] Ah, on https there's a bugzilla with a bad cert [03:40] But 5 days 5 hours? Surely we should timeout much quicker [03:40] Certainly [03:40] But should and do are different [03:40] Particularly when it comes to checkwatches [03:40] Indeed [03:41] That's the only bugwatch from that tracker [03:45] wgrant: You've commented on bug 758258 about a migration [03:45] <_mup_> Bug #758258: buildfarmjob schema is inefficient for reporting < https://launchpad.net/bugs/758258 > [03:46] That's a reasonably big effort still, so it remains suspended until we run out of low-hanging fruit [03:46] * StevenK has been looking to no avail for low-hanging fruit [03:47] There's a lot of fairly easy timeouts and OOPSes left [03:48] 2012-10-17 10:39:23 INFO Updating 1 watches for 1 bugs on https://bugzilla.filesystems.org [03:48] 2012-10-22 15:44:03 INFO An exception was raised when updating https://bugzilla.filesystems.org/ (OOPS-674539797ca55814a0c0894007b34498) [03:55] 2012-09-24 07:11:24 INFO Updating 1 watches for 1 bugs on https://bugzilla.filesystems.org [03:56] That same bugtracker caused the earlier hang [04:04] 2012-10-23 04:03:58 INFO Updating 1 watches for 1 bugs on https://bugzilla.filesystems.org [04:04] and now we wait.. [04:04] :( [04:04] 2012-10-23 04:04:10 INFO Error updating https://bugzilla.filesystems.org/: Failed to parse XML description for https://bugzilla.filesystems.org bugs [u'632']: mismatched tag: line 101, column 4 [04:04] It worked [04:04] What did you changed? [04:04] This was locally [04:05] Sure, but did you change anything [04:05] No [04:05] Ah [04:06] Maybe bugzilla.filesystems.org is blocking loganberry? [04:08] It even works via squid.internal [04:08] Bleh, are there no webservice tests for DSDs? [04:09] Not even under registry? [04:09] Not that I can see [04:09] I suspect it's a lazr.restful bug anyway [04:33] wgrant: I am disappoint. You didn't rip out contrib.glock in disgust while I was on holidays. [04:39] Indeed. [04:43] wallyworld_, wgrant: https://code.launchpad.net/~stevenk/lazr.restful/lazr.restful-choice-marshaller-none/+merge/130932 [04:47] StevenK: looks ok, but i don't know enough about the semantics of the code to be able to offer a considered opinion [04:49] StevenK: Is this circumstance actually valid? [04:50] wgrant: Bug 924291 [04:50] <_mup_> Bug #924291: AttributeError: 'NoneType' object has no attribute 'title' on package differences page < https://launchpad.net/bugs/924291 > [04:51] StevenK: It can happen, but is it valid? [04:51] parent_package_diff_status is a Choice of PackageDiffStatus, but the property returns None if the DSD's parent_package_diff is None [04:52] I thought it would usually escape earlier if the value was None [04:53] wgrant: Like I say in the description, unmarshall_to_closeup will return the entire vocab in any case. [04:53] I can change LP to just return PackageDiffStatus.PENDING and never-mind this lazr.restful branch [04:53] Ah, I see now reading the code that your argument makes sense [04:55] r=me [04:57] wgrant: Thanks [06:00] lifeless: Was lazr.postgresql intended for just schema migration stuff? There's some long lock/transaction tools that I need to find somewhere to put [06:07] wgrant: it was intended to pull out everything postgresql specific that doesn't rightfully belong in storm. [06:07] wgrant: or in LP itself. [06:07] Right [06:07] Thanks [06:07] and isn't pgbouncer specific [06:07] That's what I thought, but wanted to check [06:07] :) === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [09:15] wgrant: So, early this month you fixed a packagediff generation bug that happened when we deleted things from -proposed a bit too early and then tried to copy the orphaned binary resulting from a build [09:15] wgrant: packagediff generation is pretty late in the copy process; does that mean that this kind of situation should now completely work without us having to do weird copy dances? [09:16] Archive.copyPackage and PCJ.attemptCopy don't seem to care about the publication status of the origin SPPH [09:17] So they ought to be able to copy from a deleted SPPH that's had some binaries added to it later ... I think [09:19] wgrant: Also, did you forget to close bugs following the recent NDT, possibly? I'd have expected e.g. bug 1068616 to be closed [09:19] <_mup_> Bug #1068616: Archive.copyPackages hardcodes RELEASE pocket

< https://launchpad.net/bugs/1068616 > [09:21] cjwatson: Um, I was probably accidentally on the critical list, so missed non-criticals [09:21] As for the orphaned binary copy, yes, I believe it should all work now [09:21] But there's a catch [09:21] Also bug 1014641 (critical) [09:21] There's no way to specify the source pocket today [09:21] <_mup_> Bug #1014641: +vouchers times out

< https://launchpad.net/bugs/1014641 > [09:21] cjwatson: That's not deployed yet [09:21] Oh, sorry, that's still on the report [09:21] Confusing, it was in the LPS dump [09:22] cjwatson: Ah, yeah, it was landed and then reverted, and then landed again [09:22] Oh, the ambiguous pocket thing - right, that sounds pretty easy to fix [09:22] The first two bits are deployed [09:22] Indeed [09:22] But reviving orphaned binaries should work fine now, if you copy back to -proposed first [09:22] Or if you fix the API to allow an explicit pocket [09:22] Right, so I'm conscious that there are some situations where britney is going to create this kind of thing [09:23] e.g. 1.0-1 ftbfs on powerpc, 1.0-2 initially does as well, britney sees it's no worse than before and copies, then somebody retries 1.0-2/powerpc and it works [09:23] Note that we haven't tested it, but packagediff generation is so close to the end of the process that it surely has to [09:23] work, that is [09:24] I was contemplating beefing up test_incremental_binary_copies a bit [09:24] That might be handy [09:24] It tests about 80% of this [09:24] While you're there it may also be worth sorting out the random override issue [09:24] Since that's a matter of a .order_by(BPPH.id) and a test [09:24] Oh god this is a horrible ancestry nightmare isn't it? [09:24] No? [09:24] I don't think so [09:25] It's not a total nightmare [09:25] Last night I found vague allusions to a lot of this stuff in IRC logs from earlier in the month, but there wasn't enough to track them down to things I could fix on the spot [09:25] I don't think it'll do the override dance for an intra-archive copy, will it? [09:25] It'll just use whatever getBuiltBinaries returns [09:26] The problem with that method is that it doesn't guarantee which publication will be returned if there are multiple BPPHs for a BPR [09:26] So, if you try to copy an upload that's had its overrides changed, you're going to get a random assortment of overrides [09:26] .order_by doesn't sound like a complete fix, then [09:27] There won't be a BPPH until the build happens; and we probably want to pick up the overrides from some other architecture that's already built [09:27] getBuiltBinaries iterates through the entire set of binary publications, and IIRC uses the first one it finds for each BPR [09:27] So an order_by should fix it [09:27] Hmm? [09:27] The build will upload and do normal ancestry calculation, which is correct. [09:27] It's only copies that use getBuiltBinaries' arbitrary chooser [09:27] Otherwise you change 1.0-2 to component: main for all the architectures that already exist, and then when 1.0-2/powerpc appears it'll flip back to whatever 1.0-1/powerpc was? [09:28] Well, yes, but that's an ancient bug [09:28] Oh, right, I understand now [09:28] From early 2006 [09:28] Which we've lived with for nearly 7 years :) [09:28] https://bugs.launchpad.net/launchpad/+bug/180218 [09:28] <_mup_> Bug #180218: override mismatch race needs to be fixed

< https://launchpad.net/bugs/180218 > [09:28] There was an older one, once upon a time [09:28] Yeah, not fixing that this week [09:28] But that's the current one about the situation you describe [09:28] Mine is perhaps more insidious and easier to fix [09:29] Wrong overrides are a relatively minor problem in the development series; we have a report for them [09:29] (i.e. override mismatches between architectures) [09:29] Sure [09:29] And it's empty most of the time [09:32] But yeah, I'm a small handful of LP commits away from having britney allegedly fully working, so just trying to think of ways it might unintentionally explodify the archive in advance ... [09:33] I've been able to run it over nearly-trivial cases in raring-proposed in production and have it copy stuff successfully [09:33] As long as we have robust binary revival copies it should all be recoverable [10:25] wgrant: could you have a look at https://code.launchpad.net/~cjwatson/launchpad/db-redirect-release-uploads/+merge/130857 ? === Ursinha is now known as Ursinha-afk === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === Ursinha-afk is now known as Ursinha === yofel_ is now known as yofel [13:43] sinzui: lines 236-241 of the diff add the extra Related Projects link to the person index page [13:45] i suck. sorry wallyworld_ [13:46] np, merely an oversight [13:46] easy to miss [13:46] the rest we can discuss tomorrow, you raise good points, i wasn't sure what to remove and what to keep [13:47] * wallyworld_ off to bed [13:48] wallyworld_, oversight? I knew exactly where the change had to be, and I read the diff, and I looked over the diff for the very file you did change, then told you you needed to make the change that is clearly in the diff [13:48] don't worry, i'm not :-) === al-maisan is now known as almaisan-away [15:33] wgrant: Can you see why debootstrap/1.0.42ubuntu1 and apparmor/2.8.0-0ubuntu6 didn't get announcement mails when they were accepted into raring-proposed? I didn't think PROPOSED was special here. I think I used the API to accept the former; not sure how the latter was done. [16:13] cr3: your ml request should get done today [16:25] czajkowski: sweet, thanks so much! [16:26] cr3: well we're still checking it but updates will be on the question === matsubara is now known as matsubara-lunch === Ursinha-afk is now known as Ursinha === matsubara-lunch is now known as matsubara [17:45] wgrant: So, this random overrides thing - I'm having a hard time seeing how to trigger it, since getBuiltBinaries requires the BPPHs it returns to match the distroseries and pocket of the SPPH. How could there ever be more than one per BPN/architecturetag? [17:47] Oh, changeOverride would create a new BPPH, wouldn't it, duh === Ursinha-afk is now known as Ursinha === mordred is now known as mtaylor === mtaylor is now known as mordred === dpm_ is now known as dpm === Ursinha is now known as Ursinha-afk === timrc is now known as timrc-afk === timrc-afk is now known as timrc [21:54] cjwatson: It doesn't require that they're published, and changeOverride creates a new BPPH, indeed [21:56] cjwatson: Did you find out what happened to the debootstrap and apparmor announcements? [21:56] No [21:56] k, will investigate [21:56] Couldn't figure out where useful logs would be [21:59] You tell funny jokes [22:51] wgrant: StevenK: sinzui: http://askubuntu.com/questions/202677/nvidia-driver-doesnt-work-in-12-10 [23:25] wgrant, I forgot to ask you to take a look at Colin's db branch in reviews [23:31] sinzui: It's already on my list after he pinged me about it last night :)