Spec URL: http://www.environnement.ens.fr/perso/dumas/fc-srpms/ivman.spec SRPM URL: http://www.environnement.ens.fr/perso/dumas/fc-srpms/ivman-0.6.12-1.src.rpm Description: Ivman is a generic handler for HAL events. Originally for automounting, it can now be used to run arbitrary commands when events or conditions occur or properties are modified on your hardware (e.g., run a command when you close your laptop's lid, run a command when a particular device is attached or a particular CD is inserted, etc). To be able to mount devices automatically as a user, you should also install gnome-mount and/or pmount.
OK - Package name OK - Spec file matches base package name. OK - Meets Packaging Guidelines. OK - License (QPL/GPL) OK - License field in spec matches OK - License file included in package OK - Spec in American English OK - Spec is legible. OK - Sources match upstream md5sum: 031c763d6acc927bf2fefd7c6140247d ivman-0.6.12.tar.bz2 031c763d6acc927bf2fefd7c6140247d ivman-0.6.12.tar.bz2.1 OK - Package compiles and builds on at least one arch. OK - BuildRequires correct OK - Spec handles locales/find_lang OK - Package owns all the directories it creates. OK - Package has no duplicate files in %files. OK - Package has %defattr and permissions on files is good. OK - Package has a correct %clean section. OK - Spec has consistant macro usage. OK - Package is code or permissible content. OK - Packages %doc files don't affect runtime. OK - Package doesn't own any directories other packages own. See below - No rpmlint output. SHOULD Items: - Should include License or ask upstream to include it. - Should build in mock. Issues: 1. rpmlint says: W: ivman incoherent-subsys /etc/rc.d/init.d/ivman $servicename W: ivman incoherent-subsys /etc/rc.d/init.d/ivman $servicename W: ivman incoherent-subsys /etc/rc.d/init.d/ivman $servicename I think this is rpmlint getting confused. The pid file looks correct to me. You might doublecheck it. 2. I take it this is targeted for fc6? dbus-glib-devel doesn't exist in fc5. Everything else looks good... this package is APPROVED. Don't forget to close this NEXTRELEASE once it's been imported and built.
(In reply to comment #1) > 1. rpmlint says: > > W: ivman incoherent-subsys /etc/rc.d/init.d/ivman $servicename > W: ivman incoherent-subsys /etc/rc.d/init.d/ivman $servicename > W: ivman incoherent-subsys /etc/rc.d/init.d/ivman $servicename > > I think this is rpmlint getting confused. The pid file looks > correct to me. You might doublecheck it. Indeed rpmlint is confused by $servicename, however it is pointed out in rpmlint -i that it is a common false positive, and $servicename is indeed ivman. > 2. I take it this is targeted for fc6? > dbus-glib-devel doesn't exist in fc5. This should work in fc5 too. What is the package owning /usr/lib/pkgconfig/dbus-glib-1.pc on fc5? I intend to do these modifications to ivman: * ship an autostart file, /etc/xdg/autostart/ivman-autostart.desktop to start ivman for freedesktop compliant window managers, except for the environments known to do the automounting themselves (with a NotShowIn=XFCE;KDE;GNOME;) * In the targeted environments, where ivman would be automatically started, there is no easy way to remember to unmount devices (no icon appearing when a usb key is plugged). So I would like to have all the mounts performed by ivman be mounted with the sync option, to be more reliable, at the expense of efficiency. Does this sounds good to you? It is imported, built, owners.list is updated.
One comment. > > 2. I take it this is targeted for fc6? > > dbus-glib-devel doesn't exist in fc5. > > This should work in fc5 too. What is the package owning > /usr/lib/pkgconfig/dbus-glib-1.pc > on fc5? > This is dbus-devel on FC5. So on FC5 BuildRequires should be: dbus-devel, dbus-glib and others.
In Reply to Comment #2: Yeah, those changes sound fine to me. In Reply to Comment #3: Yeah, I meant to look up what packages they were in fc5, but didn't. So yeah, it just will require diffrent BuildRequires for fc5. Can this be closed NEXTRELEASE now?
By the way, where is ivman? I checked ftp://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS , however there is no ivman?
I thought I built it, however it isn't that bad if it isn't built, since currently there is an issue with config files in my opinion which could hurt normal users during upgrades. I submitted the issue upstream but I haven't have a definitive response which would have allowed me to do a patch.
Patrice: Any news on this package? Has upstream responded?
Not yet. I'll reask some time in the future...
Still no word from upstream? Would be good to get this imported and built...
I asked again, but no decision yet
I see that 0.6.13 was released. Does this address the config file issue you were seeing?
No, it doesn't...
ok, so what do we do here? This package has been waiting for around 3 months now. What is the config file issue you are waiting on? Can it be patched in the fedora package until upstream addresses it?
(In reply to comment #13) > What is the config file issue you are waiting on? When the user don't have any config file, the default config is put in his personal directory (in the .ivman subdirectory, if I recall well). Therefore if there is an update of the default config file it isn't taken into account for the users. This is fine for power users using ivman, but not for normal users. And I think ivman may be usefull for normal users with lightweight desktops. If this is shipped as is, it won't be possible to change users config files, although this may be desirable sometime. > Can it be patched in the fedora package until upstream addresses it? I don't think it would be wise, it hasn't even been accepted by upstream.
Yeah, that does seem suboptimal... Is it enough to keep the package from being published though? Perhaps you should push this version to devel and keep trying to get upstream to fix the issue? Did you ask about this on the upstream mailing list? Sourceforge seems broken here and I can't view the mailling list archives for this project. They do have an issue tracker, perhaps it would be good to file a bug/enhancement request there?
I asked on the mailing list. In fact the maintainer isn't very interested in maintaining ivman anymore, so I think it is better to wait before building. Moreover I have modified locally what is in fedora cvs to mount synchronously, and also I have updated to 0.6.13 (2 patches are upstreamed), but I still would like to wait for things to settle down upstream.
0.6.14 is available now. Any further news from upstream?
I have updated to 0.6.14 in cvs, but it doesn't solve that issue. There is a bad new, there could be a license issue. Indeed it is possible that the initial author used GPL code and changed it to QPL. The current maintainer added a double licensing under the GPL, but he couldn't reach all the authors... I had a discussion with the maintainer, he wasn't really happy with the ivman design, and he doesn't want to maintain ivman anymore. Finally I did something similar with ivman that I called halevt: http://www.environnement.ens.fr/perso/dumas/halevt.html Given the current situation (no system config file, maintainer not interested anymore, license issue, I did a replacement) I am willing to orphan ivman and never build it...
Oh well, such is life. Go ahead and orphan it then... remember to follow the procedure at: http://www.fedoraproject.org/wiki/Extras/PackageEndOfLife Please close this review request once you are done.
When orphaning, is the same procedure to be followed? I mean the package is not retired, simply orphaned.
I would say you should follow the procedure to cvs rm the files, and put a dead.package file in CVS. That way people will know it's not built. If someone wants to bring it back they can do so from that state. Thats probibly going to have to happen to all the other orphans at some point...
Shame this didn't work out - it's just what I'm looking for! I will have to be patient! :-)
The package is ready to be taken by another maintainer. I would even like to be co-maintainer.
Shouldn't this bug be closed in any case?
Yeah, I suppose it should. The confusing thing to end users will be that the package is in cvs and owners.list, but hasn't been built ever. :( Patrice: I will close this review now, can you use the orphan process on the package soon unless you find a co-maintainer who will build it?
No comaintainer showed up when I asked on the list. I think the best would be to mark it as dead, but orphans policy is not that clear today and my questions about orphans in a merged world wasn't properly answered when I asked on the devel list a while back. So I am waiting a bit for things to settle a bit and doc to come up before I complete the orphaning.
I didn't see your post about orphans in the merged world... link? I think the procedure is the same as it was: - cvs rm all the files - cvs add a dead.package file. - request cvsadmin to set the owner of the package to be orphan.
https://www.redhat.com/archives/fedora-maintainers/2007-May/msg00271.html After that there was somebody else asking and there was some changes done to the wiki but not all my questions were answered. I am waiting for someone (or many ones) with a knowledge of what should be done and a will to maintain that page (seems like Michael Schwendt did that before) to make things more clear before I do something precise, as long as I don't understand everything as for now. Maybe I will restart the issue some day, but I'll let a bit time for things to stabilize.
(In reply to comment #22) > Shame this didn't work out - it's just what I'm looking for! I will have to be > patient! :-) I have developped halevt which could replace ivman. Looks like hal is deprecated in favor of devicekit these days, though. I should have properly retired and orphaned ivman now.