Natively-synced packages in copy archives spam Debian developers with disallowed-component warnings

[Colin Watson]

A number of the failures in the recent test rebuild were upload failures with 'Component "non-free" not allowed in raring'. For example:

  https://launchpad.net/ubuntu/+archive/test-rebuild-20121221/+build/4096090

Not only should this upload failure not occur in the first place (because the component was overridden to "multiverse" in Ubuntu), but it certainly should not spam Debian developers with a failure they don't care about (https://lists.ubuntu.com/archives/ubuntu-devel/2013-January/036374.html).

[Colin Watson (cjwatson)]

Thanks, Tom. The .changes is functionally identical to the one uploaded to the primary archive (https://launchpadlibrarian.net/106220190/lha_1.14i-10.4_armhf.changes), so that rules out a problem with buildd configuration.

[Colin Watson (cjwatson)]

Traceback from the uploader:

Traceback (most recent call last):
  File "/srv/launchpad.net/codelines/soyuz-production-rev-16420/lib/lp/archiveuploader/nascentupload.py", line 860, in do_accept
    self.storeObjectsInDatabase(build=build)
  File "/srv/launchpad.net/codelines/soyuz-production-rev-16420/lib/lp/archiveuploader/nascentupload.py", line 1047, in storeObjectsInDatabase
    self.changes.filepath, logger=self.logger)
  File "/srv/launchpad.net/codelines/soyuz-production-rev-16420/lib/lp/soyuz/model/queue.py", line 508, in acceptFromUploader
    self.setAccepted()
  File "/srv/launchpad.net/codelines/soyuz-production-rev-16420/lib/lp/soyuz/model/queue.py", line 362, in setAccepted
    raise QueueInconsistentStateError(info)
QueueInconsistentStateError: Component "non-free" is not allowed in raring

[Colin Watson (cjwatson)]

I see two problems here:

  1) Archive.getOverridePolicy doesn't return an UbuntuOverridePolicy for ArchivePurpose.COPY. I think it probably should.
  2) Syncs from Debian produce build .changes files with Changed-By: <last uploader to Debian>, and get_upload_notification_recipients always mails Changed-By for rejections of binary uploads to non-PPA archives. This would happen if there were a binary rejection from the primary archive too; those are just rather rarer at the moment. But perhaps a decent workaround for the moment would be to ensure that notifications for copy archives only go to the archive owner, since nothing else makes much sense.

[Colin Watson (cjwatson)]

Or in fact we should probably just not mail anyone for binary upload failures to copy archives, at least for now. We already have other ways to track this kind of thing and I suspect doko isn't desperately interested in getting even more mail.

[Colin Watson (cjwatson)]

It can't have anything to do with Archive.getOverridePolicy, thinking about it - that's only used for copies at the moment. I don't quite see why NascentUpload.find_and_apply_overrides didn't work out that the binary package exists in the primary archive and use that ancestry, since it looks as though NascentUpload.getBinaryAncestry should return the appropriate publication, despite the comment in NascentUpload.processUnknownFile.

It's perfectly possible, if unlikely for something to build in a copy archive when it has never built in the primary archive, so NascentUpload.processUnknownFile should probably make sure to apply UnknownOverridePolicy to copy archive uploads. That ought to paper over this problem most of the time, but it seems to me that something else must be going on.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r16447 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/16447>.

[Colin Watson (cjwatson)]

Well, it's no worse, but it doesn't fix the problem, due to:

    if blamer is None:
        debug(logger, "Changes file is unsigned; adding changer as recipient.")
        candidate_recipients.append(changer)

[Colin Watson (cjwatson)]

All the packages that failed to upload in this way were removed from raring after the test rebuild was started. That would explain why NascentUpload didn't find any overrides to copy.

[Launchpad QA Bot (lpqabot)]

r16450 in stable (http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/16450) is part of this bug's fix.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r17138 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/17138>.