[Impact]
It is hard for a developer to determine the OOPS at errors.ubuntu.com associated with the crash file that they uploaded, especially if they have uploaded multiple .crash files. This resolves this by having daisy return the OOPS ID when the report is uploaded, which is then logged by whoopsie.
[Test Case]
1) start whoopsie in the foreground "sudo CRASH_DB_URL=https://daisy.ubuntu.com APPORT_REPORT_DIR=/var/crash/ whoopsie -f"
2) start d-feet in a terminal "d-feet &"
3) pkill -11 d-feet
4) say yes to reporting the crash
5) Observe the following in the terminal running whoopsie
Parsing /var/crash/_usr_share_virt-manager_virt-manager.py.1000.crash.
Uploading /var/crash/_usr_share_virt-manager_virt-manager.py.1000.crash.
Sent; server replied with: No error
Response code: 200
Sent; server replied with: No error
With the version of whoopsie from trusty -proposed you will see the following line:
"Reported OOPS ID 89d2d5fc-f0af-11e3-8891-fa163e373683"
You can then go to https://errors.ubuntu.com/oops/$OOPSID and see the crash you reported (it should be about the same package).
[Regression Potential]
There is little chance of a regression as we are just logging more information.
When whoopsie uploads a crash to errors.ubuntu.com the OOPS ID for the crash should be recorded by whoopsie in a log file. This would require some work on daisy's part to return the OOPS ID. This would allow one to more easily find the OOPS corresponding to a crash then going to the user page and looking at all of the most recent OOPSes to find the one you are interested in.
This may be a good target for SRU'ing to Trusty.