Require a way to copy [P]PPA packages into Ubuntu

Bug #334858 reported by Julian Edwards
20
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

We want to be able to copy PPA or Private PPA packages into Ubuntu, optionally via the distroseries upload queues as necessary.

This is required to be able to:
 * Make an API to unembargo security packages, so we can get rid of the shell script that currently does it
 * Copy partner packages from PPAs (when that's allowed) into Ubuntu (Bug #244159)
 * Allow anyone who has upload access to Ubuntu to be able to go to a PPA and initiate a package copy to Ubuntu

This will be modelled as a package upload but will not re-process the upload itself; the package will just pass through the queue and follow the existing queue rules. Security (unembargoed) uploads should not stay in the queue.

Related branches

Changed in soyuz:
assignee: nobody → julian-edwards
importance: Undecided → High
milestone: none → 2.2.3
status: New → Triaged
Changed in soyuz:
milestone: 2.2.3 → 2.2.4
Changed in soyuz:
milestone: 2.2.4 → 2.2.5
Changed in soyuz:
milestone: 2.2.5 → 2.2.6
Revision history for this message
Julian Edwards (julian-edwards) wrote :

This is dependent on the work being done in https://blueprints.edge.launchpad.net/soyuz/+spec/soyuz-delayed-copies which is nearly complete.

Changed in soyuz:
milestone: 2.2.6 → 2.2.7
Changed in soyuz:
assignee: Julian Edwards (julian-edwards) → Celso Providelo (cprov)
Revision history for this message
Celso Providelo (cprov) wrote :

archive.syncSource API is already able to copy sources (binaries and custom uploads) from private PPA directly to the ubuntu main archives (PRIMARY and PARTNER).

This feature is *only* available to members of the ubuntu-drivers and ubuntu-security teams atm.

Here is an example:

{{{
    ubuntu = lp.distributions['ubuntu']
    primary, partner = ubuntu.archives
    security_ppa = lp.people['ubuntu-security'].archive
    primary.syncSource(
        source_name='hello', version='2.2-3ubuntu4',
        from_archive=security_ppa, include_binaries=True,
        to_series='jaunty', to_pocket='Security')
}}}

Version conflicts and other copy mistakes will result in failures and consequently no changes.

On success (nothing is returned), It results in an ACCEPTED item in the corresponding upload queue (ubuntu/jaunty/+queue) containing the source in question, its successfully built binaries and custom uploads available in the original archive (partially built sources will result in new builds in the destination archive).

The accepted 'delayed-copies' will be processed during the hourly publication cycle, bugs mentioned in the changelog will be closed and private files will become public at this point. The queue item will be marked as DONE.

No email notification will be generated (missing feature, sorry).

Next step is extend the permissions to execute copies to all ubuntu uploaders, respecting their permissions.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

This is related to bug 244163 and can't be fixed yet for the same reasons.

Changed in soyuz:
milestone: 2.2.7 → pending
Curtis Hovey (sinzui)
Changed in soyuz:
assignee: Celso Providelo (cprov) → nobody
Revision history for this message
Robert Collins (lifeless) wrote :

Don't we need to force rebuilds in the primary archive always except for security unembargos? Doing otherwise will trivially cause library mismatches, FTBFS scenarios and so on.

Revision history for this message
Julian Edwards (julian-edwards) wrote :

Yes. This can be rolled up into the Package Copy Job stuff quite trivially now, since that is already in use for syncs from Debian. We just need the extra UI selection and view code logic.

Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
Changed in launchpad:
assignee: nobody → Colin Watson (cjwatson)
tags: added: qa-needstesting
Changed in launchpad:
status: Triaged → In Progress
Revision history for this message
Colin Watson (cjwatson) wrote :

This OOPSes when processing the PCJ:

Traceback (most recent call last):
  Module lazr.jobrunner.jobrunner, line 194, in runJobHandleError
    self.runJob(job, fallback)
  Module lp.services.job.runner, line 270, in runJob
    super(BaseJobRunner, self).runJob(IRunnableJob(job), fallback)
  Module lazr.jobrunner.jobrunner, line 162, in runJob
    job.run()
  Module lp.soyuz.model.packagecopyjob, line 495, in run
    self.attemptCopy()
  Module lp.soyuz.model.packagecopyjob, line 562, in attemptCopy
    unembargo=self.unembargo)
  Module lp.soyuz.scripts.packagecopier, line 686, in do_copy
    previous_version=old_version)
  Module lp.soyuz.adapters.notification, line 193, in notify
    bprs=bprs)
  Module lp.soyuz.adapters.notification, line 477, in get_upload_notification_recipients
    info = fetch_information(spr, bprs, changes)
  Module lp.soyuz.adapters.notification, line 631, in fetch_information
    changesfile = spr.aggregate_changelog(previous_version)
  Module lp.soyuz.model.sourcepackagerelease, line 649, in aggregate_changelog
    for block in Changelog(changelog.read()):
  Module lp.services.librarian.model, line 171, in read
    self.open(timeout=timeout)
  Module lp.services.librarian.model, line 161, in open
    self._datafile = self.client.getFileByAlias(self.id, timeout)
  Module lp.services.librarian.client, line 476, in getFileByAlias
    return self._connect_read(url, try_until, aliasID)
  Module lp.services.librarian.client, line 491, in _connect_read
    raise LookupError(aliasID)
LookupError: 103960041

I'll need to figure out what's going on here; I assume it's either a missing transaction.commit or passing the wrong (private) objects to notify.

Archive.syncSource (the delayed-copy path) still works. So we can *probably* deploy this anyway, but the OOPS needs to be fixed ASAP.

Revision history for this message
Colin Watson (cjwatson) wrote :

Also, non-unembargoing Archive.copyPackage calls are unaffected.

Revision history for this message
Colin Watson (cjwatson) wrote :

And unembargo-package.py is unaffected, since it doesn't pass send_email=True; it's only PCJs that do that. So, in summary, the only broken thing is the new API which must be explicitly selected, making this safe to deploy despite the problems.

tags: added: qa-ok
removed: qa-needstesting
Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
removed: qa-ok
Revision history for this message
Colin Watson (cjwatson) wrote :

r15486 seems to have cleared this up. The only mild oddity is that the BinaryPackageBuild is still on a URL for the private archive (https://dogfood.launchpad.net/~cjwatson/+archive/dogfood-private/+build/3459155), but it's actually public; this appears to be normal. Publication went off without a hitch as far as I can tell.

tags: added: qa-ok
removed: qa-needstesting
Revision history for this message
Micah Gersten (micahg) wrote :
Revision history for this message
Colin Watson (cjwatson) wrote :

Apart from removing the old copy-package.py script, I think the only thing that's missing here is a way to copy packages into the Ubuntu primary archive using the UI. Of course, as mentioned, this requires care since we should only allow including binaries in certain circumstances. This isn't urgent in any case since the API is now sufficient for us.

Revision history for this message
Launchpad QA Bot (lpqabot) wrote :
tags: added: qa-needstesting
removed: qa-ok
Colin Watson (cjwatson)
tags: added: qa-untestable
removed: qa-needstesting
William Grant (wgrant)
tags: added: package-copies
Colin Watson (cjwatson)
Changed in launchpad:
assignee: Colin Watson (cjwatson) → nobody
status: In Progress → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.