Ubuntu Cloud Archive

Comment 16 for bug 1649979

Revision history for this message

Dan Streetman (ddstreet) wrote on 2018-05-17:

#16

To clarify:

the ddebs.ubuntu.com archive is, for the most part, not useful. It contains ddebs, but only for the last few versions. Many, possibly most, coredumps we see come from older packages. So we do not really care if you sync the UCA ddebs to ddebs.ubuntu.com or not, since it's unlikely we would actually bother to use it.

in launchpad, all ddebs built for ubuntu archive packages are stored for the life of the release, and are accessible either by a rather painful navigation by browser to get the specific ddeb for the right package/version, or simply by using pull-lp-ddebs. This is why we're asking you to make the UCA ddebs available in the UCA -staging ppa.

Related to this, it would really be nice if the -staging ppa binaries actually were the same as the published binaries in the UCA archive (instead of being rebuilt in a private ppa). Having the actual debs (and ddebs) in -staging (or if you can make -proposed public) would help to debug problems with the UCA packages.

To give you an idea of what we have to currently do to debug any coredump from any UCA package binary:

1) create a new PPA
2) edit the PPA 'dependencies' to depend on the corresponding UCA release -staging ppa
3) enable building dbgsym in that PPA
4) go to the UCA -staging ppa, e.g. mitaka-staging package details page
5) go to 'copy packages', and search for the specific package/version needed
6) select the right (older) version, use private ppa from step 1 as 'destination' ppa
7) make sure 'rebuild the copied sources' is checked, and then 'copy packages'

the pkg will rebuild in our private ppa, including dbgsyms. however, it's not an exact match, since all the associated packages that it builds with aren't exactly the same as the associated pkgs that the original pkg built with. And we have to do ^ for every UCA package we want dbgsyms for. Typically, the symbols are "close enough" to use to make sense of the core file, but this obviously is not great.

if you make the UCA ddebs (and actual real identical debs would be great too, not the not-really-the-same -staging debs) available in a public ppa (like -staging) then we can simply use pull-lp-ddebs to grab the specific ddebs we need, which will be both more accurate as well as vastly faster than our currently process to debug UCA packages.

To clarify:

the ddebs.ubuntu.com archive is, for the most part, not useful.  It contains ddebs, but only for the last few versions.  Many, possibly most, coredumps we see come from older packages.  So we do not really care if you sync the UCA ddebs to ddebs.ubuntu.com or not, since it's unlikely we would actually bother to use it.

in launchpad, all ddebs built for ubuntu archive packages are stored for the life of the release, and are accessible either by a rather painful navigation by browser to get the specific ddeb for the right package/version, or simply by using pull-lp-ddebs.  This is why we're asking you to make the UCA ddebs available in the UCA -staging ppa.

Related to this, it would really be nice if the -staging ppa binaries actually were the same as the published binaries in the UCA archive (instead of being rebuilt in a private ppa).  Having the actual debs (and ddebs) in -staging (or if you can make -proposed public) would help to debug problems with the UCA packages.

To give you an idea of what we have to currently do to debug any coredump from any UCA package binary:

the pkg will rebuild in our private ppa, including dbgsyms.  however, it's not an exact match, since all the associated packages that it builds with aren't exactly the same as the associated pkgs that the original pkg built with.  And we have to do ^ for every UCA package we want dbgsyms for.  Typically, the symbols are "close enough" to use to make sense of the core file, but this obviously is not great.