Not recorded whether an error is in a -proposed or -updates package

There are two ways to approach this.

We can use the Launchpad API to check each package for each problem in the 'most common problems' API. If the version number for the most recently published version in -proposed is in the BucketVersions column family for the given problem identifier, show it in the '-proposed' filtered view of the table with the frequency value from BucketVersions.

The downside to this approach is that we do not know definitively if the crash occurred in -proposed, -updates, or the main archive since we're basing the judgement entirely on version numbers and not where each user obtained the package from. So the -proposed view might be polluted with errors that are occurring in -updates because those version numbers also existed in -proposed.

The second, though more invasive and forward-looking-only approach is to include the package origin data when creating an apport report. This could then be sent with the rest of the report to daisy, which would then maintain a separate view of the most common problems table data for each archive (ubuntu, ubuntu-proposed, ubuntu-updates, etc). We wouldn't have the pollution issue mentioned above because we'd be basing the counts entirely on the archive the errors occurred in.

Martin, Matthew, Brian, Kate, others, what do you think?

Having an accurate understanding of the archive state (-proposed, -updates, etc.) where the error was detected is necessary for figuring out appropriate next actions in an automated fashion. Would rather see the package origin data be included so we can be definitive and create bots to help, rather than rely on judgement from version number inferences.

A fast way to do this might be to continue to overload the tags. That is rather than adding just the tag "precise", it could be "precise-proposed" or "precise-updates" and use "precise" when its part of the released iso version.

Checking the current origin of the installed package seems fine to me. I'm not sure how apt even records that information, but at least seeing where the currently installed version is available from (-proposed or -updates) at the time of the crash should suffice.

Wrt. the tag, my gut feeling is that "precise proposed" would be better than "precise-proposed", as we don't break the meaning of the original distro release tags, and you can search for either of them individually. We would attach "proposed" to those packages whose version is only available in -proposed but not any other pocket, and skip the tag otherwise. Does that work for everyone?

As discussed with Evan, I'll add a "package-from-proposed" tag if the installed package version is available from -proposed (on the user's system), but not from -security and -updates.

I committed that to the Ubuntu hook now: http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2088

This bug was fixed in the package apport - 2.5.2-0ubuntu2

---------------
apport (2.5.2-0ubuntu2) quantal; urgency=low

  * data/general-hooks/ubuntu.py: Add "package-from-proposed" tag if the
    installed package version is available from -proposed, but not from
    -security and -updates. (LP: #1050853)
  * Merge fixes from trunk:
    - data/apportcheckresume: Open report file in binary mode. (LP: #1040353)
    - packaging-apt-dpkg.py: When throwing ValueErrors, show the non-existing
      package name. This makes it easier to debug such crashes.
    - launchpad.py: Replace characters from tags which are not allowed by
      Launchpad with '.' (LP: #1029479)
 -- Martin Pitt <email address hidden> Tue, 18 Sep 2012 14:51:08 +0200

Shouldn't the tagging of bugs package-from-proposed be implemented in Precise also?

Brian Murray [2012-09-20 17:30 -0000]:
> Shouldn't the tagging of bugs package-from-proposed be implemented in
> Precise also?

Yes, I agree.

Uploaded precise fix to unapproved queue.

Hello Matthew, or anyone else affected,

Accepted into precise-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Following test case in the description I confirm that the package from precise-proposed behaves in the desired way and tags bugs package-from-proposed appropriately.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package apport - 2.0.1-0ubuntu14

---------------
apport (2.0.1-0ubuntu14) precise-proposed; urgency=low

  [ Brian Murray ]
  * data/general/ubuntu.py: check to see if a package installation duplicate
    signature has been encountered previously and if so prevent bug reporting
    (LP: #1007637)

  [ Martin Pitt ]
  * data/general-hooks/ubuntu.py: Add "package-from-proposed" tag if the
    installed package version is available from -proposed, but not from
    -security and -updates. Backported from Ubuntu branch r2088.
    (LP: #1050853)
 -- Martin Pitt <email address hidden> Thu, 20 Sep 2012 21:45:51 +0200

Whoopsie now uploads the Tags field.

This is also recorded in daisy now but is not displayed in errors at all and should be so leaving that task open.

The errors frontend shows the Tags: field on an individual bucket and on the front page lists the pocket from which a package version is available. Subsequently, I think this is Fixed in errors now.