desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #134211
[Bug 1487174] Re: apport-retrace's build sandbox routine carries on if it can't find the package for an ExecutablePath
> Well trying to run get_file_package() before install_packages() didn't work out to well.
> NotImplementedError: Cannot map DistroRelease to a code name without install_packages()
Indeed, as without a config directory we can't map something like
"Ubuntu 15.04" to "wily", which we need to download the matching
Contents.gz.
I turned the warning into a fatal, which should already help:
http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2997 .
This should be okay, as realistically the first
apport.packaging.install_packages() call does not really do anything
(unless you specified extra_packages), as we usually have ProcMaps
available in reports and thus use the needed_runtime_packages() pass to
install only the packages we need instead of all Packages: plus
Dependencies:. So I think any additional potential speedup by reordering
things should be miniscule, especially since (hopefully) an unknown
ExecutablePath isn't the common case?
** Changed in: apport
Status: New => Fix Released
** Changed in: apport (Ubuntu)
Status: New => Fix Committed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1487174
Title:
apport-retrace's build sandbox routine carries on if it can't find the
package for an ExecutablePath
Status in Apport:
Fix Released
Status in apport package in Ubuntu:
Fix Committed
Bug description:
In the event that a package which provides an ExecutablePath or
InterpreterPath can not be found apport will carry on building the
sandbox but then exits a short while later (the last line in the
pasted code). I think it'd be better if apport just quit earlier.
Here's the code in question from sandboxutils.py:
# package hooks might reassign Package:, check that we have the originally
# crashing binary
for path in ('InterpreterPath', 'ExecutablePath'):
if path in report:
pkg = apport.packaging.get_file_package(report[path], True, pkgmap_cache_dir,
release=report['DistroRelease'],
arch=report.get('Architecture'))
if pkg:
apport.log('Installing extra package %s to get %s' % (pkg, path), log_timestamps)
pkgs.append((pkg, pkg_versions.get(pkg)))
else:
apport.warning('Cannot find package which ships %s', path)
# unpack packages for executable using cache and sandbox
if pkgs:
try:
outdated_msg += apport.packaging.install_packages(
sandbox_dir, config_dir, report['DistroRelease'], pkgs,
verbose, cache_dir, permanent_rootdir,
architecture=report.get('Architecture'), origins=origins)
except SystemError as e:
apport.fatal(str(e))
# sanity check: for a packaged binary we require having the executable in
# the sandbox; TODO: for an unpackage binary we don't currently copy its
# potential local library dependencies (like those in build trees) into the
# sandbox, and we call gdb/valgrind on the binary outside the sandbox.
if 'Package' in report:
for path in ('InterpreterPath', 'ExecutablePath'):
if path in report and not os.path.exists(sandbox_dir + report[path]):
apport.fatal('%s %s does not exist (report specified package %s)',
path, sandbox_dir + report[path], report['Package'])
Instead of warning with ('Cannot find package which ships %s', path) I
think that should be a fatal error. It'd probably be optimal to even
move the check for the crashing binary to the earliest place possible
in make_sandbox.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1487174/+subscriptions