I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable.

[Test Case]
One convoluted way to test this the following:
1) on a quantal system run 'do-release-upgrade -d'
2) cancel the upgrade
3) switch to the release upgrader directory '/tmp/ubuntu-release-upgrade-XYZ'
4) edit DistUpgradeController create a new line (number 407) after 'if.self.configgetWithDefault...' with the contents 'x = (10 / 0)'. This will cause the release upgrader to crash the next time it is run.
5) in /tmp/ubuntu-release-upgrader-XYZ run the following:
'sudo /usr/bin/python /tmp/ubuntu-release-upgrader-XYZ/raring --sandbox'
Observe the release upgrader crash and that you are not prompted to file a bug in Launchpad.
----
I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable.

[Test Case]
One convoluted way to test this the following:
1) on a quantal system run 'do-release-upgrade -d'
2) cancel the upgrade
3) switch to the release upgrader directory '/tmp/ubuntu-release-upgrade-XYZ'
4) edit DistUpgradeController create a new line (number 407) after 'if.self.configgetWithDefault...' with the contents 'x = (10 / 0)'. This will cause the release upgrader to crash the next time it is run.
5) in /tmp/ubuntu-release-upgrader-XYZ run the following:
'sudo /usr/bin/python /tmp/ubuntu-release-upgrader-XYZ/raring --sandbox'
Observe the release upgrader crash and that you are not prompted to file a bug in Launchpad.
----
I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable.

[Test Case]
One convoluted way to test this the following:
1) on a quantal system run 'do-release-upgrade -d'
2) cancel the upgrade
3) switch to the release upgrader directory '/tmp/ubuntu-release-upgrade-XYZ'
4) edit DistUpgradeController.py create a new line (number 407) after 'if.self.config.getWithDefault...' with the contents 'x = (10 / 0)'. This will cause the release upgrader to crash the next time it is run.
5) in /tmp/ubuntu-release-upgrader-XYZ run the following:
'sudo /usr/bin/python /tmp/ubuntu-release-upgrader-XYZ/raring --sandbox'
Observe the release upgrader crash. If you inspect the contents of the crash file, /var/crash/_usr_bin_do-release-upgrade.0.crash you'll notice that with the current version of apport, additional system information is not collected - you will not find Dependencies in the .crash file. With the version of apport from -proposed you will find this.
----
I was testing bug 1067542 again and ran into a situation where release upgrade crash was unreportable because the binary had changed.
Digging into the issue DistUpgradeApport.py from update-manager / ubuntu-release-upgrader sets ExecutablePath = '/usr/bin/do-release-upgrade', however ProcCmdline = '/usr/bin/python /tmp/update-manager-xyz/quantal' (from the dist upgrade tarball).
Then when add_proc_info calls _check_interpreted (in apport/report.py) ExecutablePath is temporarily set to '/tmp/update-manager-xyz/quantal' and the ExecutableTimestamp is calculated using that ExecutablePath. Later, on when collect_info (in apport/ui.py) is run we use the "real" ExecutablePath, '/usr/bin/do-release-upgrade' in this example, which will have a different ExecutableTimestamp than the one written to the report during _check_interpreted.
This ultimately, makes reporting crashes in the release upgrader not reportable.