Ticket #281 (closed defect: fixed)

Opened 13 years ago

Last modified 12 years ago

notify-osd misleadingly reports that print jobs have completed

Reported by: mitchb Owned by:
Priority: normal Milestone: Fall 2009 Release
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:  scp:#181


As noted on zephyr earlier, I printed a document from
OpenOffice? to meadow on opus (a Jaunty -cluster machine),
and immediately received a notify-osd alert that my
print job had completed on meadow. It was actually
reporting that it had finished spooling the job to
cups.mit.edu, and of course the job on the printer had
yet to start, and might well have gone on to fail.

This is, admittedly, an upstream issue. However, it's
going to seriously mislead and screw with all cluster
users who won't understand what it really means, so we
probably want to try to suppress it. Unfortunately, it
is a very nice looking notice interface... too bad
it "lies." It might be neat if we could get the old
xconsole messages through this interface (though that
does have the issue that you can't scroll back to review
messages, and if you're away from the keyboard, you'll
miss them).

Change History

comment:1 Changed 13 years ago by geofft

  • Milestone set to Summer Deployment

Adding this as a summer deployment issue.

comment:2 Changed 13 years ago by broder

I spent a while source diving this morning to see if I could figure out what's going on and what our options are.

First, the libnotify messages are being generated by system-config-printer. Specifically, in JobViewer?.notify_completed_job in jobviewer.py of the system-config-printer source.

Unfortunately, it looks like the only time that anything is done to specifically identify notifications from the printer is when pynotify.init is called (the call is added by debian/patches/26_notification.patch). The argument to pynotify.init goes to notify_init.

Switching to the notify-osd source, that argument ends up being sent as the first argument to the notification dbus service for every notification that gets requested. Incoming notifications result in calls to stack_notify_handler in src/stack.c, which as far as I can tell, has absolutely no ability for the user to customize notifications.

I find it also pretty telling that none of libnotify1, notification-daemon, and notify-osd install anything at all into /etc.

Also, I think that this should be re-milestoned for "Fall Release"; "Summer Deployment" tickets have generally been crippling bugs that make Debathena unusable for large groups of people, while Fall Release is generally really unfortunate - but non-crippling - UI bugs. I think this qualifies as the latter.

comment:3 Changed 13 years ago by broder

  • Milestone changed from Summer Deployment to Fall Release

comment:4 Changed 13 years ago by broder

  • Upstream bug set to scp:#181

Filed a ticket with system-config-printer upstream.

comment:5 Changed 13 years ago by broder

Given that we have no mechanisms for filtering messages at the libnotify level, I see a few options for us to actually fix this:

  1. Suppress all libnotify messages
  2. Debathenify system-config-printer
  3. Re-write all printer URIs to be ipp2:// or athena:// or something instead of ipp://

I object to the first because I think it's a worse UI - Ubuntu applications expect to be able to send messages to users through libnotify.

I object to the second because I think the amount of work and the maintenance cost far outweigh the negative UI of this

I object to the third because it would have to be done at cups.mit.edu (or alternatively mmanley's magic F5-balanced CUPS servers), which means that /all/ clients would have to support this weird ipp2:// URI format, which is unacceptable.

So given that, from my perspective, none of our mechanisms for fixing this bug are justified by the severity of the bug, I'd like to propose that we bump this bug back to Upstream Utopia, and continue poking system-config-printer upstream to fix this within a somewhat reasonable amount of time.

geofft objects to bumping it back, so I'd like to ask release-team to look at this at our next meeting.

comment:6 Changed 12 years ago by geofft

  • Status changed from new to proposed

I "fixed" this in r23952 by installing a translation file to change the string from "Document foo has finished printing on bar" to "Document foo has been sent to bar for printing." Having tested that this approach works, I've uploaded the package to -proposed.

We should still pursue the upstream option; they may just want to change the message in a similar fashion rather than considering dropping it altogether or adding a lot of logic to differentiate local and remote printers.

comment:7 Changed 12 years ago by broder

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.