Description of problem: the hal-callout script: /usr/lib/hal/scripts/libgpod-callout is never called, since hald does not search in this directory for its callouts Version-Release number of selected component (if applicable): libgpod-0.7.2-5.fc12.i686 How reproducible: 100% Steps to Reproduce: 1. get the pod of hald-runner 2. attach strace (strace -p $HALD_RUNNER_PID -f -o /tmp/hal.log) 3. attach an ipod 4. kill strace, checkout log (grep libgpod-callout /tmp/hal.log) ------------------------------- 1186 access("/usr/libexec/libgpod-callout", X_OK) = -1 ENOENT (No such file or directory) 1186 access("/usr/libexec/scripts/libgpod-callout", X_OK) = -1 ENOENT (No such file or directory) 1186 access("/usr/bin/libgpod-callout", X_OK) = -1 ENOENT (No such file or directory) 1186 access("/usr/libexec/libgpod-callout", X_OK) = -1 ENOENT (No such file or directory) 1186 access("/usr/libexec/scripts/libgpod-callout", X_OK) = -1 ENOENT (No such file or directory) 1186 access("/usr/bin/libgpod-callout", X_OK) = -1 ENOENT (No such file or directory) ------------------------------- Actual results: - SysInfoExtened file is not written Additional info: - specifying the a valid hal search path via --with-hal-callouts-dir should do the trick (e.g /usr/libexec)... - in Fedora 11 hal still searches in /usr/lib/hal/scripts and so it works fine in F11, but in F12 hal seems not to check /usr/lib/hal/scripts anymore.
Looks like hal-0.5.13 changed the default path¹. Perhaps I missed some announcement of this on fedora-devel, but I wouldn't have expected a library that is in "maintenance mode"² to change the path it searches for callouts. It would be simple to add the -with-hal-callouts-dir back, but when I added that upstream I spent time reading the HAL specs precisely so that the default would work out of the box on numerous distributions. It's a shame to lose that and potentially have other distros broken as well. :/ Further, the hal specification documentation upstream still says³: "To be portable across operating systems, third party packages providing callouts must therefore only use $libdir/hal/scripts" I think the documentation is out of date, but I don't honestly know what the recommended best practice is now. Richard, can you enlighten me on this? Should the hal packages be using --libexecdir=/usr/lib/hal as the upstream commit (fa05be9) suggests (or even --libexecdir=%{_libdir}/hal to keep things backward compatible)? (I'm not really sure what was so broken with the old path that it needed to be changed in a backward incompatible way in a minor hal release.) ¹ http://cgit.freedesktop.org/hal/commit/?id=fa05be9 ² According to http://www.freedesktop.org/wiki/Software/hal ³ http://cgit.freedesktop.org/hal/tree/doc/spec/hal-spec-properties.xml#n394
Richard, do you know what we should expect from hal here? I think this change in a minor point release was unwise, more so because hal is in maintenance mode.
Ping? Richard, what do you think? This seems more like a hal bug to me, as changing the hal default at this point doesn't provide any improvement that I can see and breaks at least libgpod's callout, which follows the existing hal documentation. For that reason, I'm assigning it to hal. Feel free to change it back and comment if you disagree. :)
(In reply to comment #2) > Richard, do you know what we should expect from hal here? I think this change > in a minor point release was unwise, more so because hal is in maintenance > mode. I didn't know the default changed. Could we change it back using configure for f12, and just use the new default in F13?
I think we should do as the upstream commit which changed this suggests¹: "Multilib isn't cool, but /usr/lib64/hal/scripts/ is even less. This switches to libexecdir to be able to set the proper install location. --libexecdir=/usr/lib/hal should be given now at configure time." (Or --libexecdir=%{_prefix}/lib/hal in our case I suppose.) I believe the intent of the change upstream was not to change the default location of the scripts, but to ensure that they always ended up in /usr/lib/hal, as the spec calls for, rather than being placed in /usr/lib64 on x86_64 platforms. Sorry for the delayed reply. :/ ¹ http://cgit.freedesktop.org/hal/commit/?id=fa05be9
I'm not totally comfortable using --libexecdir=/usr/lib/hal -- that's going to affect other parts of HAL too. Can we just back out the upstream patch in F12?
I guess I don't know all the issues with hal. But perhaps this is something that should be settled upstream? That's where the recommendation to use --libexecdir=/usr/lib/hal comes from. If that's not wise, then it shouldn't be recommended upstream. I can't see how leaving it untouched in F-13/devel is going to make any sense. Whatever is used, --libexecdir=$something should be used I believe. Honestly, I think changing it at all for software in maintenance mode was a mistake from upstream. I've built libgpod packages for rawhide and placed the hal callout scripts in %{_libexecdir}/scripts so that they work. I can do similarly for F-12 as well, but I really wanted to see us use something which I can make the default in libgpod upstream. And that's going to be a pain at this point I guess, as upstream hal doesn't match their own spec documents and I can't reasonably get the script location via pkg-config in libgpod's autoconf. It might be simpler for me to suggest that we install the callouts somewhere in $PATH since that would work and hal will hopefully continue to respect that. Fortunately, Christophe is working on making libgpod use udev for the callouts, so we will be able to drop hal support soon and forget all of this unneeded confusion. ;) FWIW, Christophe is at Mandriva these days and he points out that they use %define _libexecdir %{_libdir}/hal in their current hal packages. That would result in keeping the hal script dir the same as it has been for ages. Perhaps t hat's a reasonable alternative for us? Otherwise, using /usr/lib/hal as the specification requires would be my next suggestion. Thanks for listening. I hope I don't sound annoyed with you Richard, I'm not. I'm just frustrated because I spent the time to try and make things work out of the box upstream in libgpod and now it looks like that was wasted effort.
FWIW, it would be great if we could just use pkg-config to get both fdi dir and script dir from hal. I made a patch to do so a while back but never submitted it because I thought hal was in maint mode and there didn't seem any point. But I'd be happy to look at that again and submit something if you think it would be worthwhile.
Would it be an option to fix the problem for now in libgpod by putting the hal-callout binary in the directory where hal expects it? This would immediately fix the package which is now broken since more than two months... :-( I fully agree that we should try to find a final and good solution which probably also involves an update of hal. But I assume since hal is a very critical package it has to be considered carefully and probably needs some further discussion. IMHO this should not block fixing the problem for now in libgpod. ;)
libgpod-0.7.2-8.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/libgpod-0.7.2-8.fc12
libgpod-0.7.2-8.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
In F13 and F14 SysInfoExtended is correctly written by libgpod (using udev). I'm unsure about F12 since I can't test it anymore.