** Changed in: canonical-devices-system-image Importance: Undecided => High
** Changed in: canonical-devices-system-image Status: New => Confirmed ** Changed in: canonical-devices-system-image Milestone: None => r1 ** Changed in: canonical-devices-system-image Assignee: (unassigned) => Canonical Devices Products (canonical-devices-products-team) -- 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: Confirmed Status in Ubuntu Download Manager: In Progress Status in “ubuntu-download-manager” package in Ubuntu: In Progress 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp