Red Hat Bugzilla – Bug 459119
Patch needed from upstream to handle NotificationClosed reason
Last modified: 2008-08-23 21:31:55 EDT
Created attachment 314323 [details]
libnotify-closed-reason.patch (from changeset 3005)
Description of problem:
The 'closed' signal now carries an extra parameter, and we need to apply a patch from upstream to handle that.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
def closed_cb(n, reason=None):
if __name__ == '__main__':
loop = gobject.MainLoop ()
n = pynotify.Notification("title", "text")
n.connect ("closed", closed_cb)
2.Close the notification
This breaks system-config-printer's printer event notifications.
Let me make sure I understand that.
Upstream changed the api between the daemon and the client-side ?
But there have not been any releases (daemon or client-side) with the new api, so how exactly does this break s-c-printer ?
Or is this a problem where Ubuntu ships api-changing patches ?
The best solution would certainly be for upstream to release new versions that have the latest api...
(In reply to comment #1)
> Upstream changed the api between the daemon and the client-side ?
Unfortunately so, but apparently in order to bring it in line with the freedesktop spec.
> But there have not been any releases (daemon or client-side) with the new api,
> so how exactly does this break s-c-printer ?
Fedora devel currently has a notification-daemon package (0.3.7.90-1.svn3009) that uses the new API, which of course breaks because libnotify is still using the old API.
> Or is this a problem where Ubuntu ships api-changing patches ?
No, nothing to do with Ubuntu.
> The best solution would certainly be for upstream to release new versions that
> have the latest api...
Or we could stick to released versions ourselves.. :-)
Reverting to notification-daemon-0.3.7 would also fix this.
Ah, ok. In that case, why don't you go ahead and put that patch into rawhide ?
Built in rawhide now.