apport-retrace's rebuild-package-info makes bad assumption

Bug #1677405 reported by Brian Murray
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Apport
Triaged
Low
Unassigned

Bug Description

It seems that the --rebuild-package-info switch assumes that the report being rebuilt is from the same system which is doing the rebuilding. I say this because it calls report.py's add_package_info, but then that calls fileutils.py's find_file_package (which has no information about the report), and that in turn calls the packaging backend's get_file_package() which is a lot smarter if it is passed the release and architecture from the report. As an example consider how sandboxutils.py calls get_file_package():

92 pkg = apport.packaging.get_file_package(l, True, pkgmap_cache_dir,
93 release=report['DistroRelease'],
94 arch=report.get('Architecture'))

The best thing to do is probably call get_file_package() directly from apport-retrace but the sandbox would need to be created first. Or pass a switch that'll ensure the report's Package field is created when the sandbox is being generated.

Changed in apport:
importance: Undecided → High
Revision history for this message
Brian Murray (brian-murray) wrote :

The documentation actually indicates that this should only be done on the system which experienced the crash:

       -R, --rebuild-package-info
              (Re-)generate Packages: and Dependenencies: fields before retracing. This is particularly useful if you want to retrace a .crash report before it was completed by running it through the UI data collection phase. However, this only works when you run this on the very same system where the crash happened.

Changed in apport:
status: New → Invalid
status: Invalid → Triaged
importance: High → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.