Try calling unexisting functions on GtkDialog

Bug #1258112 reported by Sebastien Bacher
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apturl (Ubuntu)
update-manager (Ubuntu)
Michael Vogt

Bug Description

That's a side effect of the refactoring which has been done in

_action_done() is calling "self.window_main.start_available/error", or window_main is a GtkDialog not an UpdateManager object anymore, so it doesn't have those functions...

Tags: saucy
Revision history for this message
Sebastien Bacher (seb128) wrote :

That's creating for apturl

way to reproduce
- call apturl-gtk apt:<somebinarynotinstalled
- click install
- when the password prompt shows, hit "esc" on the keyboard

you get the stacktrace

"Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/defer/", line 483, in _inline_callbacks
    result = gen.throw(excep)
  File "/usr/lib/python3/dist-packages/AptUrl/gtk/backend/", line 57, in commit
    self._action_done(self.ACTION_INSTALL, False, False, str(e), None)
  File "/usr/lib/python3/dist-packages/UpdateManager/backend/", line 70, in _action_done
    self.window_main.start_error(False, error_string, error_desc)
TypeError: <lambda>() takes 0 positional arguments but 3 were given"

Changed in update-manager (Ubuntu):
status: New → Confirmed
importance: Undecided → High
tags: added: saucy
Revision history for this message
Dylan McCall (dylanmccall) wrote :

This looks like a bug in apturl. It calls into Update Manager's Python modules with its own bogus 'window_main' object (which happens to provide a similar interface to Update Manager, until recently). I didn't realize this was happening when I originally refactored it: I'd been working on the assumption that Update Manager's code was all private. Sorry about that!

Frankly, though, this seems very broken on apturl's part, and from a cursory glance I don't think its sane to fix it from update-manager's end. I had submitted a few patches to apturl for an earlier issue, so this could be patched over in a similar fashion: copy the missing interface into apturl's monstrous 'UpdateManager' / 'window_main' lookalike and run away before it gains sentience.

Can someone explain why it is structured this way? I feel like we'd be better off if apturl just used PackageKit directly, or if we're going to reuse this dialog for some reason if it at least launched Update Manager over the command line instead of using Python modules from other applications that (as far as I can tell) carry no guarantees for portability.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@Dylan: thanks for the comment, I'm not sure why apturl has been done this way (maybe packagekit was not providing what was needed by then?).

I'm Ccing Michael, maybe he can provide some context/guidance there.

On how we fix the issue, I've no strong opinion, I would prefer avoiding too much churn/rewrite in a LTS cycle (though it's still early and apturl is relatively small so it should be ok to test it and find issues before release)

Revision history for this message
Michael Vogt (mvo) wrote :

@Dylan - (re)using update-manager backend was not a good idea, this needs to be decoupled. again. I can try to look at this in the next couple of days.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

When I specified <>, I understood that Ubuntu Software Center was going to replace apturl completely. And "xdg-open apt:whatever" does launch USC as expected. So what is apturl's current purpose? Is it just for systems on which USC is not installed?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Michael, are you still going to look at that?

Changed in update-manager (Ubuntu):
assignee: nobody → Michael Vogt (mvo)
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.