Description of problem: Notifications appear to be using notify-send instead of libnotify which means that every notification creates a new icon in the bottom of gnome-shell. Version-Release number of selected component (if applicable): xchat-2.8.8-7.fc15.x86_64 (also tested i686) How reproducible: 100% Steps to Reproduce: 1. Enable tray balloon notifications in xchat 2. have a notification happen. Actual results: New notify-send notification forked with an xchat icon for every notification. Expected results: Use the xchat icon already present for notifications.
See fix for this at: http://sourceforge.net/tracker/index.php?func=detail&aid=3109838&group_id=239&atid=100239
This patch is already applied in xchat-2.8.8-7.fc15. Looks like it doesn't work.
ah, cool that the patch is in there, I haven't had a chance to look into the SRPM to diagnose properly yet. I wonder what is going wrong then. It is only a minor annoyance when waking up and finding 20 odd Freenode notifications/icons. If there is a way to clear them all in one go that would also make me happy :)
CCing the author of the non-working patch.
You need to uncheck "Enable system tray icon" in your xchat preferences.
Hi Christopher, That got rid of the tray icon which is also there, but it still uses notify-send :(
Ugh, I see the problem... xchat is dynamically loading libnotify like so: nn_mod = g_module_open ("libnotify.so.1", G_MODULE_BIND_LAZY); but: % rpm -ql libnotify | grep so /usr/lib64/libnotify.so.4 /usr/lib64/libnotify.so.4.0.0
Hi Christopher, Nice find. I quickly added a symlink for that and that made it work.
Created attachment 490659 [details] Load the correct library So, here's a fuller analysis with a patch. During my first glance, I missed another g_module_open call a few lines above the g_module_open that I quoted. The code first does nn_mod = g_module_open ("libnotify", G_MODULE_BIND_LAZY); which looks for "libnotify" which fails, then "libnotify.so" which fails, then "libnotify.la" which fails. Then, it looks for "/usr/lib64/libnotify.so". On developer systems with libnotify-devel, this file exists, so it happily loads libnotify support for us. However, on user systems, this does not exist which leads to that g_module_open call outright failing. This explains why it appeared to be working for me and presumably Owen too, but not for you. Then, it goes and tries to load the versioned module. Naturally, that fails. At that point, it then falls back to use notify-send. I'm not sure the motivations for dynamically loading the library instead of linking directly, but I think a correct minimalistic fix is to do: - nn_mod = g_module_open ("libnotify", G_MODULE_BIND_LAZY); + nn_mod = g_module_open ("libnotify.so.4", G_MODULE_BIND_LAZY); This adds the newest versioned library at the top of the check, and still keeps the old versioned library. However, it also removes the devel only library from the list which reduces the chances that developers will be blind to this issue in the future. There's no real reason to look there anyway since most users just won't have that installed. I've performed a scratch build with this fix available here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2982847
(it still doesn't really solve the underlying problem that the so version could change at any point in the future, and this bug would come back again, but we'd need to a rebuild at that point anyway... direct linking would make it really easy to spot, though, whereas the dynamic loading only sort of masks the issue.)
Thanks for working on this so quick. Finding it really hard to find fault with Fedora 15 now ;) Will be using it to give talks at the MySQL UC next week so ultimate test for me :)
Created attachment 490670 [details] Better patch, link directly against libnotify (untested) I built the previous minimal patch as xchat-2.8.8-8.fc15. That said, I think this is the better patch, and what should get sent upstream. As notify-send is provided by libnotify, it doesn't really make sense to expect that to be there but not the library directly. We already would need to update the build for when the soname changes, so we might as well get automatic detection by linking directly against it. And the code becomes cleaner this way.
(In reply to comment #12) > Created attachment 490670 [details] > Better patch, link directly against libnotify (untested) Note, I've compile tested this both with and without libnotify, just haven't run tested it yet.
Created attachment 490680 [details] Better patch, link directly against libnotify Updated patch, compiles and tested to work.
xchat-2.8.8-9.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/xchat-2.8.8-9.fc15
Comment on attachment 490680 [details] Better patch, link directly against libnotify submitted upstream as http://sourceforge.net/tracker/?func=browse&group_id=239&atid=100239
Package xchat-2.8.8-9.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing xchat-2.8.8-9.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/xchat-2.8.8-9.fc15 then log in and leave karma (feedback).
xchat-2.8.8-9.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.