Bug 208737 - Review Request: ivman - Generic handler for HAL events
Summary: Review Request: ivman - Generic handler for HAL events
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-10-01 09:11 UTC by Patrice Dumas
Modified: 2009-02-01 19:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-06 01:45:58 UTC
Type: ---
Embargoed:
kevin: fedora-review+


Attachments (Terms of Use)

Description Patrice Dumas 2006-10-01 09:11:29 UTC
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.

Comment 1 Kevin Fenzi 2006-10-03 05:11:13 UTC
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.



Comment 2 Patrice Dumas 2006-10-03 08:23:59 UTC
(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.

Comment 3 Mamoru TASAKA 2006-10-03 09:15:57 UTC
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.

Comment 4 Kevin Fenzi 2006-10-03 15:35:38 UTC
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?

Comment 5 Mamoru TASAKA 2006-10-13 16:55:06 UTC
By the way, where is ivman?
I checked
ftp://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS ,
however there is no ivman?

Comment 6 Patrice Dumas 2006-10-13 17:42:02 UTC
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.

Comment 7 Kevin Fenzi 2006-11-12 01:47:16 UTC
Patrice: Any news on this package? Has upstream responded?

Comment 8 Patrice Dumas 2006-11-12 19:52:35 UTC
Not yet. I'll reask some time in the future...

Comment 9 Kevin Fenzi 2006-12-03 23:11:12 UTC
Still no word from upstream? Would be good to get this imported and built... 

Comment 10 Patrice Dumas 2006-12-04 00:14:33 UTC
I asked again, but no decision yet

Comment 11 Kevin Fenzi 2006-12-30 19:42:47 UTC
I see that 0.6.13 was released. Does this address the config file issue you were
seeing? 

Comment 12 Patrice Dumas 2007-01-02 16:40:39 UTC
No, it doesn't...

Comment 13 Kevin Fenzi 2007-01-02 17:15:10 UTC
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?


Comment 14 Patrice Dumas 2007-01-02 17:26:20 UTC
(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.

Comment 15 Kevin Fenzi 2007-01-04 00:13:28 UTC
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?

Comment 16 Patrice Dumas 2007-01-04 00:26:52 UTC
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.

Comment 17 Kevin Fenzi 2007-02-24 02:43:22 UTC
0.6.14 is available now. 

Any further news from upstream? 

Comment 18 Patrice Dumas 2007-02-24 12:12:47 UTC
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...

Comment 19 Kevin Fenzi 2007-02-26 18:44:17 UTC
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. 

Comment 20 Patrice Dumas 2007-03-02 13:38:14 UTC
When orphaning, is the same procedure to be followed?
I mean the package is not retired, simply orphaned.

Comment 21 Kevin Fenzi 2007-03-02 17:08:24 UTC
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... 

Comment 22 David Anderson 2007-03-12 15:12:15 UTC
Shame this didn't work out - it's just what I'm looking for! I will have to be 
patient! :-)

Comment 23 Patrice Dumas 2007-03-12 15:29:11 UTC
The package is ready to be taken by another maintainer. I would
even like to be co-maintainer.

Comment 24 Jason Tibbitts 2007-06-06 00:06:08 UTC
Shouldn't this bug be closed in any case?

Comment 25 Kevin Fenzi 2007-06-06 01:45:58 UTC
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? 

Comment 26 Patrice Dumas 2007-06-06 17:36:37 UTC
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.

Comment 27 Kevin Fenzi 2007-06-06 19:32:43 UTC
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. 

Comment 28 Patrice Dumas 2007-06-06 20:50:54 UTC
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.

Comment 29 Patrice Dumas 2008-09-18 14:27:36 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.