PPAs should create backtracable packages

@wgrant - how much work is this? Its currently in the stakeholder queue, but I'm wondering if its too small for that and really just a maintenance scale problem.

For PPAs it is maintenance-scale work (mostly just needs testing, I believe). For the primary archive it is significantly harder, but still probably too small for a full feature squad.

We can enable it for PPAs without finishing primary archive support if we add a safeguard to prevent ddebs from being copied into primary archives.

https://bugs.launchpad.net/launchpad/+bugs?field.tag=ddebs is the list of remaining bugs that I know about. All of those bugs pertain to the primary archive, because they deal with overrides or the separate debug archive.

The stakeholder request is for PPAs alone; given your description I
think we should escalate this bug, do just PPAs alone with the
safeguard you mention and come back to the primary archive at a later
date. I'm going to optimistically tag this escalated and let jml &
flacoste know so if they want to schedule it differently they can.

Quick question for the non-LP dev here :-) Why is this something that
doesn't work in the archive? I though the archive already had packages
that supported apport? Wouldn't we just be porting the same thing over
to the PPAs?

On Tue, Apr 5, 2011 at 3:31 AM, Ted Gould <email address hidden> wrote:
> Quick question for the non-LP dev here :-)  Why is this something that
> doesn't work in the archive?  I though the archive already had packages
> that supported apport?  Wouldn't we just be porting the same thing over
> to the PPAs?

AIUI the one for the archive is done externally to LP - it lives in an
entirely different archive with a predictable url (ddebs.ubuntu.com or
something). Its constructed using output from regular builds, but run
separately. To migrate that to one generated by archive builds means
migrating stuff around. (Sorry for the vagueness ;))

The primary archive currently uses a terrible hack in our sbuild to copy the ddebs to ~/public_html on the buildds. A non-LP script is then run to grab those from all the non-virt builders, and put them on ddebs.ubuntu.com. This doesn't work for PPAs for a few reasons:

 - Ew, gross.
 - PPA builders are reset for every build, so ~/public_html doesn't survive long enough to have its contents grabbed.
 - PPA builders build for lots of different archives, so it's hard to work out where the ddebs should go.
 - Expanding the hackish ddebs.ubuntu.com scripts to work for thousands of archives sounds like a terrifying ordeal.

Thanks guys, I understand now.

I looked at this a bit last week. The main difficulty now is that PPA ddebs don't follow their deb's overrides, so they are not correctly superseded. In particular pkg-create-dbgsym overrides the priority to extra.

The quick (and possibly best) fix is to override ddebs to match the debs even for PPAs.

I concur with William, we need to keep ddebs in lockstep with debs.

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

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

Thanks for fixing this! I was told that I need to adjust something in
my debian/rules files regarding stripping the binaries for this to work.
But, I'm not sure what that is. Is there a link somewhere that I could
read about it?

 Thanks,
  Ted

@ted Actually, it seems it can be enabled transparently at the PPA level on the +admin page. I think you probably need to ask a LOSA to turn on the feature for you. Just let us know the PPA(s) you are interested in bloating with ddeb.