Merge lp:~brian-murray/apport/retrace-package-versions into lp:~apport-hackers/apport/trunk
Status: | Merged |
---|---|
Merged at revision: | 2791 |
Proposed branch: | lp:~brian-murray/apport/retrace-package-versions |
Merge into: | lp:~apport-hackers/apport/trunk |
Diff against target: |
200 lines (+50/-21) 3 files modified
apport/sandboxutils.py (+22/-4) backends/packaging-apt-dpkg.py (+21/-13) test/test_backend_apt_dpkg.py (+7/-4) |
To merge this branch: | bzr merge lp:~brian-murray/apport/retrace-package-versions |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Martin Pitt (community) | Needs Fixing | ||
Review via email: mp+210308@code.launchpad.net |
Description of the change
These changes to apport and its retracing process will, in some cases, attempt to install the specific package version that the client was using when they experienced the crash.
It does this by examining the report's Package and Dependencies keys to determine the version of the package used. However, this is incomplete in that the lookup for returning a package to which a file belongs (get_file_package used for items in ProcMaps) is unaware of package versions. Given that _search_contents is searching each pocket individually we would know the pocket from which the package came, so perhaps we could do another search using those two things. Do you have any ideas?
I've tested these changes using some crashes and corresponding coredumps I received from the error tracker. I added some information to apport-retrace to determine how many of the packages remained without a version:
/mnt/sec-
57 packages have a version, 38 do not.
/mnt/sec-
9 packages have a version, 2 do not.
/mnt/sec-
60 packages have a version, 4 do not.
/mnt/sec-
85 packages have a version, 20 do not.
/mnt/sec-
115 packages have a version, 17 do not.
/mnt/sec-
47 packages have a version, 11 do not.
/mnt/sec-
30 packages have a version, 0 do not.
/mnt/sec-
68 packages have a version, 41 do not.
/mnt/sec-
59 packages have a version, 48 do not.
/mnt/sec-
102 packages have a version, 4 do not.
/mnt/sec-
1 packages have a version, 55 do not.
So it seems like there are still some improvements to be made. I've also renamed a variable from c to cache and as c is short for continue in ipdb and this made it hard to debug cache.
8 -
Bikeshedding, I know, but I like the empty line here better as the following code is in a different flow branch/context.
22 + # first, grab the versions that we captured at crash time
As there is no "second", perhaps just "# create a package -> version map from report"?
34 + return [(p, pkg_vers.get(p, 'None')) for p in pkgs]
This needs to be None, not 'None'. get() defaults to None as fallback, so just pkg_vers.get(p) will do.
43 + if pkg in report['Package']:
This could fail in weird corner cases if it matches a substring or even the version number. Let's use this instead:
if report[ 'Package' ].startswith( pkg + ' ')
45 + if version:
46 + pkgs.append((pkg, version))
47 + else:
48 + pkgs.append((pkg, None))
This needs to be indented by a block, as version is otherwise not defined.
The other changes look good to me. This still needs a test case. This can be tested by adjusting test_install_ packages_ versioned( ) in test/test_ backend_ apt_dpkg. py, which currently uses Ubuntu precise. There are plenty of different versions in -updates to choose from :-), i. e. selecting a version from precise final should download that version instead of current precise-updates.
> However, this is incomplete in that the lookup for returning a package to which a file belongs (get_file_package used for items in ProcMaps) is unaware of package versions.
If you are speaking of plugins or other things with undeclared Depends:, and thus we don't have the version of the package that we reverse-mapped from ProcMaps, then we lost; we should just continue to install the most current version of the package. If you mean something else, I'm afraid I don't understand. As long as we have a package version in Package: or Dependencies:, that's the one we should install, and we have the report object available in all places which are concerned about package installation.
Thanks for working on this!