On Wednesday, May 14, 2014 01:07:51 Robert Park wrote: > On Tue, May 13, 2014 at 5:47 PM, Bjoern Michaelsen > > <[email protected]> wrote: > >> > ... e.g. trivially: mark crashers 48hours after the upgrade > >> > as 'potentially an upgrade sideeffect' or somesuch? > >> > >> Probably not retroactively. But I imagine it would be fairly easy to > >> add info to future error reports asking if do-release-upgrade (or > >> whatever) was running at the time. > > > > That would be very useful indeed. I assume the version data sent to > > errors.ubuntu.com in these cases to be wrong and poisoning the well > > anyway: > > - the client will send an error report with the application version the > > package> > > manager reports to be installed > > > > - the application crashed will actually be a older, different one. > > This has bit me a couple of times, although I didn't understand what > was happening at the time. > > I've seen certain python tracebacks in errors.ubuntu.com that, if you > check the version number specified in the crash, you find that the > code causing the traceback literally does not exist (in that version). > The only explanation is that the user was running an older copy, which > crashed, but the report contains the version number of the updated > package. > > > It would be ideal to fingerprint the crashed binary and compare it to the > > version installed on disc, and skip reporting if those differ. > > In the case of python programs you'd want to be sure to fingerprint > all the various .py files that might be loaded... probably better to > fingerprint every file in the package, if any differ then the report > is invalid.
If packages are crashing during an upgrade, that's still a bug, it's just a different one. Scott K -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
