=== jamesh_ is now known as jamesh === tasdomas_afk is now known as tasdomas === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === tasdomas is now known as tasdomas_afk [15:06] StevenK: sorry, it's in archivepublisher, not archiveuploader, because custom uploads [15:06] StevenK: it appears to actually be in each CU implementation [15:07] cjwatson: Yes, I just determined that, but thanks. [15:23] wgrant: The semantics of BuilderStatus.ABORTED on the master side seem a bit different from what we want from BuildStatus.ABORTED. BuilderStatus.ABORTED ends up in BuildFarmJobOld.jobAborted, which sets the status to BuildStatus.NEEDSBUILD; I think we want BuildStatus.ABORTED to end up in BuildStatus.CANCELLED. [15:23] But maybe that means that (a) we want it to be called CANCELLED on the slave side, (b) perhaps this isn't quite so compatible with the rescue case after all? [15:23] cjwatson: It depends on the origin state [15:24] BUILDING + ABORTED -> NEEDSBUILD [15:24] CANCELLING + ABORTED -> CANCELLED [15:24] IOW it should depend on that, not depends on that right now? [15:24] (Since I don't see that in the code) [15:24] Yeah [15:25] That's how it probably should work [15:25] Mkay [15:25] The slave doesn't need to know why it's being cancelled [15:25] That's purely a master-side policy decision [15:25] The slave may be being rescued, or it may be being cancelled. [15:26] They are identical from the slave POV. [15:26] OK. Bit confusing for BuildStatus.ABORTED not to necessarily be jobAborted, but I suppose there are only so many verbs. [15:27] Well [15:27] jobAborted is never called atm. [15:27] Because ABORTED is only ever hit after a rescue [15:27] In which case the job is no longer assigned to the builder, so there's no job to call jobAborted on. [15:28] An ABORTED slave for a BUILDING build should probably be an OOPS [15:28] Because I can't see how that could occur [15:29] It's quite possible it is an OOPS right now, then [15:31] jobAborted might not even make sense. [15:31] The job is cancelled [15:32] handleStatus_ABORTED might call jobCancelled when status was CANCELLING, and either set it back to NEEDSBUILD or OOPS and set to FAILEDTOBUILD for any other status [16:31] wgrant: https://code.launchpad.net/~cjwatson/launchpad/buildstatus-aborted/+merge/176990 [16:39] cjwatson: I think that looks fairly sane [16:40] I'll have to think about it [16:40] Well [16:40] And try it [16:40] Until it breaks [16:52] cjwatson, wgrant: https://code.launchpad.net/~stevenk/launchpad/no-dead-custom-uploads/+merge/176995 [16:56] StevenK: the setComponents description in customupload.py should probably be more generic [16:57] StevenK: and don't you want target_series.enabled_architectures instead of .architectures? [16:57] - """Set self.version and self.arch (if applicable).""" [16:57] + """Set instance variables based on decomposing the filename.""" [16:58] Seems fair [16:58] cjwatson: That's a question, do we want to copy custom uploads for arches which are disabled? [16:58] I don't think so [16:58] That's more a question for you, or infinity [16:58] That was the raring(?)/armel case [16:59] Right. This also gives us grace to disable them from the get go, and then yay, no custom uploads on first publish [16:59] Once it's disabled, I think we want to pretend it doesn't exist, it's just that we can't delete it easily [17:02] Well, the raring/armel case would still have worked [17:02] Because this is for the target arch check [17:02] But yes [17:02] enabled_architectures should be the default [17:34] https://code.launchpad.net/~cjwatson/launchpad-buildd/fix-abort/+merge/177003 *phew* === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [21:56] wgrant: Is there a plausible way to get a callback in buildd-manager when a build goes to ABORTED (for the bit during cancellation that needs to wait for that), or do I just have to poll? [21:57] cjwatson: You have to poll. I'd suggest using the separate handleStatus_ABORTED and just working off the state [21:57] Rather than doing it as part of the cancellation function [21:57] Hm, yeah, that makes sense. [21:58] Unless you want to rewrite buildd-manager's state machine [21:58] No :-) [21:58] Which somehow seems unlikely.. [21:58] Still need a timeout which I cancel, but I guess I can manage that [21:58] Yeah, I'm not quite sure how to do the timeout. [21:59] Possibly store is as a local attribute in buildd-manager [21:59] It means that a restart will reset the timeout, but meh [21:59] Really doesn't matter [21:59] And is probably cleaner [21:59] Why not just reactor.callLater? [21:59] A good point. [21:59] Well [21:59] A restart would stop that from working [22:00] Though I still need to store the Deferred somewhere [22:00] eg. I start cancelling a build, then buildd-manager restarts [22:00] If you just naively use callLater then it will never time out [22:01] So, I guess, ideally it would see slavestatus == BUILDING and masterstatus == CANCELLING, and call abort() and set a timeout [22:02] If it seeis slavestatus == ABORTING and masterstatus == CANCELLING, it might have to ensure that a timeout is set. [22:05] Maybe the simplest answer is just to check each time SlaveScanner notices a masterstatus == CANCELLING build, since it's polling every 15 seconds anyway [22:05] It could easily just keep count of a multiple of that [22:05] Not very Twisted, but [22:07] Yeah, indeed [22:08] If we were really trying hard then we could add a DB column on Builder for the timeout [22:13] That would be trying altogether too hard. === _mup__ is now known as _mup_