← Back to team overview

touch-packages team mailing list archive

[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 Ubuntu
Touch seeded 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