touch-packages team mailing list archive

[Pat McGowan <pat.mcgowan@xxxxxxxxxxxxx>]

** Changed in: canonical-devices-system-image
       Status: Confirmed => In Progress

** Changed in: canonical-devices-system-image
    Milestone: ww05-2015 => ww07-2015

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-download-manager in
Ubuntu.
https://bugs.launchpad.net/bugs/1341685

Title:
  When unconstrained, udm sometimes downloads files to wrong location

Status in the base for Ubuntu mobile products:
  In Progress
Status in ubuntu-download-manager package in Ubuntu:
  Fix Released
Status in ubuntu-download-manager package in Ubuntu RTM:
  In Progress

Bug description:
  I'm working on making the s-i tests more robust and I've run into an
  odd situation, where udm sometimes stores its downloaded files using
  an incorrect path, and not the one that s-i (which is unconstrained)
  requests.  This only appears to happen when the full s-i test suite is
  run.  When run in isolation, the test succeeds.

  Here's a log of the createDownloadGroup call I'm making:

  createDownloadGroup:
  [Record(url='https://localhost:8943/gpg/blacklist.tar.xz',
  destination='/tmp/tmpe7mo8qm9/ubuntu/cache/keyring.tar.xz',
  checksum=''),
  Record(url='https://localhost:8943/gpg/blacklist.tar.xz.asc',
  destination='/tmp/tmpe7mo8qm9/ubuntu/cache/keyring.tar.xz.asc',
  checksum='')]

  url is the source url, destination is the local path to save the file
  in.  This call produces incorrect destination paths in the 'finished'
  signal:

  FINISHED: dbus.Array([dbus.String('/home/barry/.local/share/ubuntu-
  download-manager//usr/lib/telepathy/mission-
  control-5/Downloads/blacklist (20).tar.xz'),
  dbus.String('/home/barry/.local/share/ubuntu-download-
  manager//usr/lib/telepathy/mission-control-5/Downloads/blacklist
  (20).tar.xz.asc')], signature=dbus.Signature('s'))

  Notice the very strange directory udm chooses which is definitely not
  the path requested, and in fact doesn't exist.  This matches the
  observed behavior that after a succesful group download completion
  (i.e. no errors occur), I assert that the requested destination path
  exists, and in the failing test it does not.

  I suspect some state is not getting reset in udm.

To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1341685/+subscriptions