[00:08] wgrant: bzr mv lazr.jobrunner-0.11.tar.gz dist/ [00:09] cjwatson: blargh, oops [00:09] cjwatson: Fixed, sorry [00:10] np [00:41] Huh. I set lp.distributions["ubuntu"].redirect_release_uploads to True, and yet https://launchpad.net/ubuntu/raring/queue?queue_state=1 shows anna having gone to the Release pocket :-( [00:41] * cjwatson wonders what he got wrong [00:42] I don't suppose poppy uses a different tree? [00:43] Well, except this is process-upload, not poppy as such [00:44] Unless I was in slightly too much of a rush and beat the rollout to pepo ... [00:45] That was it. Phew. [00:46] Yeah, appservers are done early on [00:46] pepo not so much [00:47] cjwatson: I can probably fill you in on a secret. we webops watch for activity from certain users - you're one of the lucky ones - and deliberately break things when you're on, just for our twisted amusement. [00:47] lol [00:47] Some of the devs have gotten in on this, and do similar, but release NDTs at those times. [00:48] Heh, wgrant "I'm sorry for your loss" [00:48] cjwatson: http://www.xfos.com.au/tears.jpg so yeah, drink up mon! [00:49] spm: I already assume computers are malevolent; operators being malevolent is just a logical extension [00:49] c [00:49] clearly spm's *s* expands to Simon, of BOFH. [00:49] the p is derived from Rick. [00:50] applied to, perhaps [02:04] Hm [02:05] Something increased the registry 99% render time from about 1.7s to 2.4s between the 19th and the 21st [02:05] And it remains high [02:06] That coincides well with a large number of private projects query changes [02:29] wgrant: if you have a spare moment today, could you take a look at my preliminary experimentation with setting the correct binary package components? the extra joins in the binary overrides query are needed to get the associated source package release to get the spr component, but performance may be an issue. is what i've done on the right track? [02:29] https://code.launchpad.net/~wallyworld/launchpad/package-defaults-192076/+merge/131509 [02:32] wallyworld_: Hm, doing it in the override queries is an interesting approach [02:33] * wallyworld_ has no idea about soyuz [02:33] i just tried to gather the info that was needed [02:34] maybe i can do another query later in the workflow [02:34] i'm also unsure how to do the distro validity check [02:38] wallyworld_: So, the main place this is a problem is in NascentUpload.processUnknownFile [02:38] * wallyworld_ looks at that method [02:40] It's a bit sad that you've chosen possibly the worst bit of Soyuz to work on [02:40] i have no idea what's good and what's bad [02:40] The override stuff is particularly hideous, as it follows a design which I intended to be followed up by a major refactoring cleanup pass [02:42] the calculateSourceOverrides() method seems to implement the rules in bug 120052, so i was doing a similar approach for binary packages [02:42] <_mup_> Bug #120052: Component mapping for new source packages < https://launchpad.net/bugs/120052 > [02:43] or so it seems to me anyway [02:43] wallyworld_: Right, but you'll see that NascentUpload uses UnknownOverridePolicy.getComponentOverride directly [02:44] does NascentUpload process binary packages? [02:44] since that's what the bug is referring to [02:44] Yes. [02:44] It processes both source and binary uploads [02:44] hmmm. ok. so binary packages are processed there and also in the code i've touched [02:45] The code you've touched is mostly for copies [02:45] copyBinariesTo() [02:46] Which are somewhat interesting, but post-date the bug by some years [02:46] They're not the common case, even today [02:46] so, if NascentUpload is changed, the copy stuff should be changed too i guess [02:46] to be consistent [02:46] Sort of [02:47] The copy overrides stuff is pretty awful [02:47] I don't quite remember how that side of things works with respect to the queue [02:47] so, i assume that NascentUpload has enough info to find the spr associated with a binary, then i can go from there [02:48] Right, when uploading a binary we always have a target build, which has a related SPR [02:49] how do i check if a component is valid for a distroseries? [02:50] That's recorded in the ComponentSelection table [02:50] However [02:50] however... [02:50] Are you using SPR.component? [02:50] I haven't read the MP in detail [02:50] yes [02:50] That's incorrect, sadly. [02:50] You need to find SPPH.component, for some relevant SPPH [02:51] Which is probably BinaryPackageBuild.current_source_publication [02:51] my brain hurts [02:51] SPR.component is set only once, when the SPR is created in the DB for the first time [02:51] ok, i haven't seen any data, i was just guessing based on attribute names [02:51] For lots of Ubuntu packages, they're first imported from Debian [02:52] So they appear first in main in the Debian primary archive, so SPR.component == main [02:52] Then they're copied into Ubuntu, where the SPPH.component is overridden to universe [02:52] The binaries should default not to main, but to universe [02:52] Even though SPR.component still == main [02:53] ok. could i perhaps just add an override mapping from main->universe? [02:53] You may now be getting the rationale behind my campaign to unify uploads and copies [02:53] Nope [02:53] It won't always be universe in Ubuntu [02:53] It could be main [02:53] or restricted [02:53] or multiverse [02:54] sure, but i mean just for the default mapping [02:54] So, the general rule is that if a new binary has no existing ancestral component, it should inherit the component of its build's current SPPH [02:56] ok, so i look in ComponentSelection with spph.component to see if it is valid for the distroseries [02:56] if valid, use that, if not valid, what do i do then? [02:56] just use universe? [02:58] Well [02:58] I'd just always use SPPH.component, probably [02:58] The SPPH is in the relevant distroseries [02:58] If it's not, crashing is OK [02:58] ok, and if there isn't one? [02:58] raise an exception [02:59] That's a more interesting question [02:59] We already have an issue today with builds where there is no current source publication [02:59] Usually because the source was supereseded/deleted before the build finished [03:00] eg. http://launchpadlibrarian.net/120668537/aYDS2Qq6K4jADFvNDYo0RyGBld1.txt [03:00] And I think there's a bug for that [03:00] ok, that can be for some other branch to fix i guess [03:00] so above you said "sort of" when i asked about ensuring both places were consistent - copy and upload [03:00] if i change upload, then copy has to change too i would think [03:00] So, I'd use SPPH.component, assume it's valid, use the current default mechanism if it's not set [03:01] You need to preserve the current default mechanism for sources, anyway [03:01] (processUnknownFile is used for both sources and binaries) [03:01] yes, i wasn't going to touch sources [03:02] I have to hope that StevenK remembers how missing copy overrides work [03:02] i guess target_build = None for sources? [03:02] It's relatively modern and I have repressed that memory [03:02] Um [03:02] That's one way [03:03] You'll need to redesign the way processUnknownFile is called [03:03] missing copy overrides seems to use the archive component or defaults to "universe" [03:03] So it can be given some context [03:03] ok, i haven't looked at the code fully yet [03:03] so, is using the archive component correct then for mising copies? [03:04] Oh, as in archive.default_component? [03:04] yes [03:04] If it's set, sure [03:04] It overrides the traditional default logic [03:04] the code defaults to universe if it is not set [03:05] But only for partner/PPA [03:05] Well [03:05] IIRC it defaults to universe unless [SB]PR.component is contrib or non-free, in which case it defaults to multiverse [03:05] Right? [03:05] that's force sources i think [03:05] for [03:05] not binaries [03:06] Today it's meant to go: ancestry.component, archive.default_component, [SB]PR.component -> universe/multiverse [03:07] The bugfix will be: ancestry.component, (if binary) build.current_source_publication.component, archive.default_component, [SB]PR.component -> universe/multiverse [03:07] I think [03:08] i think it looks in spph first, and then uses a default mapping for unknown [03:08] Right, it will always look up the [SB]PPH ancestry first [03:08] default mapping is contrib/non-free -> multiverse [03:09] everything else -> universe [03:09] Right, that's the last resort [03:09] above, build.current_source_publication.component = spph.component, right? [03:10] current_source_publication is an SPPH, right [03:11] ok, i'll give it a go. i might delay doing the extra query when copying binaries so that only unknown ones are processed that way [03:11] rather than doing the extra joins up front [03:12] Yeah, definitely. [03:12] i wonder how many copied binaries are unknown [03:12] It happens most often with kernel SRUs and security updates [03:12] But it's relatively very rare [03:12] ok. thanks for all the help [03:13] The plan was to rewrite find_and_apply_overrides to basically use lp.soyuz.adapters.overrides for everything, but it never got done [03:13] i haven't come across find_and_apply_overrides yet [03:14] ah, it's in NascentUpload [03:14] Right [03:14] It's what calls processUnknownFile [03:14] It's the original implementation of the override logic [03:15] Copies didn't respect overrides until 18 months ago [03:15] so we have 2 implementations, do they do the same thing? [03:15] ie give the same result? [03:15] Mostly except sort of not [03:15] The idea was that lp.soyuz.adapters.overrides would be the One True Implementation [03:15] But the old one was never destroyed, in true LP style :( [03:15] so maybe i should at least make upload and copy do the same thing then [03:16] and delete the old code [03:16] That sounds slightly too adventurous [03:16] For a first adventure into Soyuz [03:16] Although it would be a good tour, I guess [03:16] isn't it just the find_and_apply_overrides method to be replaced? [03:16] with calls to the adaptor [03:16] mostly [03:17] It's unlikely to be as smooth as we hope [03:17] As we don't have publications here [03:17] is there adequate test coverage? [03:18] Not adequate enough that I'd deploy it without extensive manual QA, but probably enough for development. [03:19] ok, i'll have a play around and see what falls out. but if i do it, i'll have to beg for help with qa [03:19] With the history of this stuff, I would be QAing it personally regardless of who wrote it and had already QAed it, don't worry [03:20] The archiveuploader tests are some of the most archaic we have [03:20] * StevenK can recall that about his overrides policy code [03:20] ok, thanks. it may be that i chicken out [03:21] but i'd like to get rid of inconsistent, "duplicate" code [03:21] where possible [03:21] Definitely [03:22] This is an example that really needs it, but it's not the easiest way to start off in Soyuz. [03:22] So we'll see [03:23] StevenK and I probably know both sides of this code reasonably well [03:23] So can unstick you as required [03:23] ok, thanks [03:24] it's hard because i have no domain knowledge and don't know where to find data to help me understand the code :-) [03:24] but, we'll see [03:24] wallyworld_: I think your first step is to print out http://behlerblog.files.wordpress.com/2012/06/frustrated-kit.jpg [03:25] hah, i did that when i first used zope [03:25] Tell me about it, so did I. [03:26] *And* I had to learn Soyuz at the same time [03:26] a good debugger is absolutely mandatory [03:26] But you had Soyuz experience! [03:26] wgrant: Sure, with using it! [03:26] lol [03:26] Tells me absolutely nothing about how the code hangs together. [03:26] That reminds me of my first lp patch. [03:27] StevenK: so, same with women [03:27] I was using grep to find things and I needed like 5 windows for grepping different things. [03:27] nigelb: you need an IDE with code navigation features [03:27] much easier [03:27] I'm guessing you use pycharm? [03:27] nigelb: you obviously were changing a simple part of LP then [03:28] yup [03:28] ajmitch: Heh, yes. [03:28] I need to get back to LP dev. Been lazy. [03:28] s/lazy/smart [03:29] ^ I was trying to be diplomatic [03:29] i was joking :-) [03:29] lp is nice once you get to know and love it [03:29] s/love/not want to kill yourself/g [03:29] *kill yourself because of [03:30] it's just like any lrge software system with lots of legacy [03:30] That's true. [03:30] wallyworld_: stockholm syndrome is real [03:30] ajmitch++ [03:30] lol [03:30] hahah [03:36] sadly i have to pause the fun soyuz stuff to deal with some ec2 hate mail [03:37] ajmitch: I'll admit, fixing LP bugs was among the most satisfying bugfixes I've done. [03:38] When I did the mouseover for bug titles thing, a lot of people pinged me say they love it ;) [03:38] (granted it took like 3 attempts at landing to actually land) [03:41] wgrant: have you seen ec2 failure with "ClosedError: Connection is closed" but the tests pass locally? [03:42] wallyworld_: In what sort of test? [03:42] a couple of doc tests [03:42] Hm [03:42] eg xx-bug-also-affects.txt [03:42] If they're the only failures and not very relevant to your changes, just lp-land I guess [03:42] Hm [03:43] This is for the +distrotask change? [03:43] yes [03:43] could be relevant [03:43] but i would expect a local failure also [03:43] Yeah [03:43] Perhaps ec2 again to be safe [03:43] yeah :-( [03:43] Won't be a significant delay, as we are unlikely to deploy again today [03:43] well, here's hoping for 2nd time lucky [05:28] lifeless: Did you see that sentry has a js logger thing? [05:28] Hehe, I was going to setup sentry for python logging when I noticed it :) [06:57] nigelb: yah, did you see the branch for oops that adds that ? [06:58] imbrandon was working on a revised version [06:58] lifeless: hah. no. [06:58] awesome. [06:58] nigelb: https://code.launchpad.net/js-oopsd [07:02] \o/ [07:02] Nice. [07:06] StevenK, are you around? [07:09] deryck: https://code.launchpad.net/~adeuring/launchpad/bug-1067736/+merge/131527 [07:10] adeuring, got it. [07:21] deryck: https://bugs.launchpad.net/launchpad/+bug/1068817 [07:21] <_mup_> Bug #1068817: Person.assigned_specs is an attractive nuisance < https://launchpad.net/bugs/1068817 > [07:36] deryck: I am now, but not really as it were. [07:36] StevenK, right. I replied on abentley's MP. We just need to get that landed, and I assumed you were done with it. [07:37] deryck: Link me, sorry? [07:38] StevenK, https://code.launchpad.net/~abentley/launchpad/person-assigned-specs-in-progress/+merge/130888 [07:38] StevenK, last comment from me. [07:38] deryck: Well, obviously :-) [07:38] Just trying to be clear :) [07:40] deryck: I am concerned about the NULL thing, since it may leak data or provide results that are not wanted, so then please do land that branch, but also please investigate to make sure that the NULL doesn't sneak in for the actual code. [07:41] StevenK, there is no NULL in the code. that was a manual substitution we did to test the query. [07:41] StevenK, the actuall code-generated query uses two values from the enum. [07:43] deryck: Ah. What I do to test SQL like that is to run a single test with LP_DEBUG_SQL=1 to grab the actual SQL, change the id's for say person or what not and then run it [07:43] StevenK: We were trying to be clever, and failing. [07:43] StevenK, cool, thanks for the tip. [07:44] StevenK, so we're cool then? [07:45] deryck: Yes. I'm happy to approve it and you guys can land it if you wish? [07:45] StevenK, thanks! [07:46] deryck, abentley: Done. === almaisan-away is now known as al-maisan [09:32] rick_h_: Could you please review this? https://code.launchpad.net/~abentley/launchpad/milestone-spec-privacy/+merge/131560 === al-maisan is now known as almaisan-away === yofel_ is now known as yofel [13:17] deryck: https://code.launchpad.net/~adeuring/launchpad/filter-private-product-RosettaApplication/+merge/131613 === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === matsubara is now known as matsubara-lunch === matsubara-lunch is now known as matsubara === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha