Comment 2 for bug 682692

I investigated the openswan case, and came up with this timeline:

 - Source uploaded to origin, amd64 built, i386 build stuck in queue
 - 1st copy: 00:27:24, source and amd64 copied, destination i386 build created due to missing i386 binaries
 - 1st publish: 00:38:33
 - Origin i386 build started: 00:52:11
 - Origin i386 build finished: 01:00:11
 - Origin i386 build uploaded and published
 - Destination i386 build started: 01:49:54
 - Destination i386 build finished: 01:56:45
 - Destination i386 build uploaded: 01:57:12
 - 1st copy deleted: 02:11:32
 - 2nd copy: 02:11:50, source, i386, amd64 copied, despite conflicting i386 build
 - Destination i386 build published: 02:15:22
 - 2nd publish: 02:17:59

Normally the copy checker will forbid a copy if a conflicting source has pending, building or unpublished builds. The last case is what we have here -- the conflicting build is sitting in the Accepted queue. It's handled by this bit of getBuildStatusSummariesForSourceIdsAndArchive:

            if (source_pub.status in active_publishing_status and
                    summary['status'] == BuildSetStatus.FULLYBUILT and
                    not source_pub.archive.is_copy):
                need_unpublished.add(source_pub)

The active_publishing_status check is the problem. The source had been deleted moments before the copy, so the build status was summarised as FULLYBUILT, and the copy was permitted. I don't know why the active_publishing_status check is there, but it looks wrong to me.