Unembargoing packages via the API doesn't seem to apply overrides correctly

Pre-implementation notes:

AFAICS, this will affect any (delayed) copy where the source package release component has been overridden from a component not in the distroseries.upload_components.

The issue is that, for delayed copies, the component is not yet overridden when the PackageUpload is accepted, as it does not yet have a publishing history. The check that is happening during acceptFromCopy() ends up at PackageUploadSource.checkComponentAndSection() which currently only considers the SourcePackageRelease.

So, I plan to add a caveat to PackageUploadSource.checkComponentAndSection() that will, for delayed copies, use the component from the (soon-to-be) ancestry, rather than the SPR.

I played around with testing this on dogfood with the following test plan:

   0 Ensure that ~michael.nelson/+archive/pocketsphinx is private
   1 Upload a new version of pocketsphinx to ~michael.nelson/+archive/pocketsphinx
     that is for contrib component (Done). It will be overridden to main when
     published. Run ppa-run.sh.
   2 Wait for i386 build to build successfully (Done).
   3 in a harness (or the API if available), do the archive.syncSource()
     with binaries included, as shown in
     https://lp-oops.canonical.com/oops.py/?oopsid=1405B2440 and verify
     that it fails with the same traceback.
{{{
>>> ubuntu = getUtility(IDistributionSet)['ubuntu']
>>> ubuntu.main_archive
<Archive at 0xae2c10c>
>>> ubuntu.main_archive.title
u'Primary Archive for Ubuntu'
>>> primary_archive = ubuntu.main_archive
>>> myppa = getUtility(IPersonSet).getByName('michael.nelson').ppas[0]
>>> myppa.title
u'Pocketsphinx packages for karmic'
>>> karmic = ubuntu['karmic']
>>> ret_val = primary_archive.syncSource(from_archive=myppa, include_binaries=True, source_name='pocketsphinx', to_pocket='Security', to_series='karmic', version='0.5.1+dfsg1-0ubuntu1+ppa1')
}}}

although the test was invalid as I didn't have a private PPA the first time. But while going through this, I realised that the same fix needs to be done for the builds being included in the copy (see PackageUploadBuild.checkComponentAndSection()), and the test will need to be updated to test this also.

So, this won't land in 3.1.12, but I'll aim to land it first thing in the next release.

Is this a re-roll candidate then?

On Tuesday 15 December 2009 15:10:48 Данило Шеган wrote:
> Is this a re-roll candidate then?
>

No, I think we'll punt it to the next release now, it's best not to rush it.

Cheers.

OK, after fixing the issue for copied binaries also, I retested this on dogfood successfully:

http://pastebin.ubuntu.com/343727/

I'll get a re-review and land it.

Fixed in devel r10067 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/10067>