==> Making package: haskell-dbus-core-parsec3 0.8.3.1-1 (Sat Sep 4 21:59:39 CDT 2010)
==> Checking Runtime Dependencies...
==> Checking Buildtime Dependencies...
==> Retrieving Sources...
-> Found dbus-core-0.8.3.1.tar.gz
==> Validating source files with md5sums...
dbus-core-0.8.3.1.tar.gz ... Passed
==> Extracting Sources...
-> Extracting dbus-core-0.8.3.1.tar.gz with bsdtar
==> Removing existing pkg/ directory...
==> Starting build()...
Configuring dbus-core-0.8.3.1...
Setup: At least the following dependencies are missing:
text ==0.7.*
Aborting...
error: Build failed
as for udisksevt efficiency:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
3850 dpx-infi 20 0 31676 6548 3228 S 0 0.2 0:00.04 udisksevt
you see, it take not so much memory. even zsh uses more! CPU usage is even lesser - most of time udisksevt just sleeps waiting for a D-Bus event. so the performance isn't a problem.
as for alternatives, besides the self-written something (bash script, C program etc) I don't know any udisks-based programs (I don't speak of major DE like GNOME of course).
as for advantages - I don't know I find it useful, maybe someone else will find it useful too. This is what community contributions are for after all
the heavy build dependencies are solvable by binary packages. I think I could try to setup a repository if it is necessary.
]]>berbae 4326 4302 0 09:14 tty1 00:00:00 /bin/bash /home/berbae/bin/udisksvm
berbae 4360 4326 0 09:14 tty1 00:00:00 udisks --monitor
It uses traydevice to put an icon in systray and to manage a menu for mounting/unmounting.
As much of the time, the script is waiting to read a line from a fifo, it doesn't use any cpu time.
Can you explain the advantages to use your program over that backgrounded bash script ?
For me it's easy to maintain and to add functionalities into it as I choose to.
But for udisksevt, it's a heavy task to build it on a machine which doesn't use the haskell development environment for other tasks.
So if you want, can you explain why you prefer haskell as development environment over C or C++ for example, which are more generally accessible ?
Present some advertising for your program, to incite the usage of it, over other choices...
Thanks
I presume this application does the same as the new libfm in the pcmanfm-project: http://blog.lxde.org/?p=768 ?
oh, I hadn't seen your message, sorry
not exactly. AFAIK libfm operates with PCManFM and works only if PCManFM window is open. UDisksEvt works independently of file manager (e.g. I don't like PCManFM, I use ROX-Filer instead) and also it is a daemon.
So when a 'changed' uevent is emitted from a device which is an optical one ('optical disk' property)
sadly, according to udisks documentation and my own examination the 'IsDeviceOpticalDisc' property only set when optical disc is inside already. here we have a some kind of race condition - the event is already in process, trigger is activated, but the correct property values are not set yet, so the program doesn't work properly. the fact it works for you is that you use shellscript which is rather slow than needed to get this behaviour. I experienced this problem already - the mount event has such drawback. I inserted a one second delay to fix this.
Anyway, this process needs careful testing and debugging. I have much free time now, so it will be done soon
UDisks daemon emits a 'Changed' signal from device and 'DeviceChanged' signal from itself when CD/DVD is inserted or removed ... - apparently, there is no information of what exactly happened with the device, this signal is emitted both on insertion and removal and maybe on something else ...
I tested a bash script to automount a cdrom/dvd on insertion.
It uses 'udisks --monitor', 'udisks --show-info' and 'udisks --mount'. The script seems to correctly detect the reason of the 'changed' uevent from device, and can then trigger the correct action.
I can share with you the criteria I use for that (may not be perfect, but it works for me) :
First I noticed that the output of the command 'udisks --show-info', launched after an uevent occured, shows the values after the uevent is done, ie the resulted values.
So when a 'changed' uevent is emitted from a device which is an optical one ('optical disk' property), ie a cdrom or a dvd, and the property 'is mounted' is false,
if the property 'has media' is true, it can only be the result of the 'changed' uevent, ie a cdrom/dvd was inserted.
Because, on my machine, a mounting/unmounting of a cdrom/dvd doesn't generate a 'changed' uevent from the device, but a 'job-changed' instead.
So, in this case, the only possible cause of a 'changed' is an insertion which resulted in the 'has media' becoming true.
And following the same reasoning, if the property 'has media' is false, it can only be the result of the removal of the cdrom/dvd.
Only a insertion/removal can 'changed' from an unmounted cdrom/dvd, and that toggles the value of the 'has media' property
The 'job-changed' uevent seems to detect the mounting/unmounting. So these events can be differentiated.
As I said, I tested it in a script, and it works as expected on my installation.
Maybe you can adapt that to your program, or find a better and more satisfying solution.
I hope you good development times in expanding the possibilities of your program.
On my machine, the device for my 'Optiarc DVD RW AD-7200S' is created at start up, so there always exists a /dev/sr0 device.
When I insert a cdrom, a 'changed' uevent is generated, not a 'added' one.
The README says :
<trigger name> must be one of 'added', 'mounted', 'unmounted', 'removed' without
quotes. Other names can be used, but such sections will be ignored.
So the 'changed' uevent cannot be used, and consequently a mounting of the cdrom cannot be triggered.
I may be wrong; in that case could you explain what I miss here?
Or could you add that functionality in the next release, please?
Because what I need is a complete control over any removable media supports, using only one program.
]]>This is definitely backward-uncompatible change in dbus-core library. I'll try to make bugfix soon.
...
yes, there are massive changes in dbus-client. I have to rewrite some code. I don't think it will take much time though
I will wait till you release a new version, to try a new automatic build with Bauerbill, and stay for now with the udisksevt 1.0-1 package which I succeeded to build/install.
Thanks.
the problem is more serious than I thought. There are some problems with dbus-client-0.4 itself. I'm making a workaround right now - downgrading to dbus-client-0.3 in all affected packages.
]]>==> Starting build()...
runhaskell Setup.hs configure
Configuring udisksevt-1.0...
Warning: Unknown extensions: TupleSections
Warning: This package indirectly depends on multiple versions of the same
package. This is highly likely to cause a compile failure.
package udisksevt-1.0 requires parsec-2.1.0.1
package network-2.2.1.7 requires parsec-2.1.0.1
package dbus-core-0.8.3.1 requires parsec-3.1.0
runhaskell Setup.hs build
Preprocessing executables for udisksevt-1.0...
Building udisksevt-1.0...
[1 of 7] Compiling UDisksEvt.Log ( UDisksEvt/Log.hs, dist/build/udisksevt/udisksevt-tmp/UDisksEvt/Log.o )
[2 of 7] Compiling UDisksEvt.Datatypes ( UDisksEvt/Datatypes.hs, dist/build/udisksevt/udisksevt-tmp/UDisksEvt/Datatypes.o )
[3 of 7] Compiling UDisksEvt.Disk ( UDisksEvt/Disk.hs, dist/build/udisksevt/udisksevt-tmp/UDisksEvt/Disk.o )
[4 of 7] Compiling UDisksEvt.DBus ( UDisksEvt/DBus.hs, dist/build/udisksevt/udisksevt-tmp/UDisksEvt/DBus.o )
UDisksEvt/DBus.hs:36:21:
Not in scope: data constructor `RemoteObject'
UDisksEvt/DBus.hs:40:25:
Not in scope: data constructor `RemoteObject'
UDisksEvt/DBus.hs:44:33:
Not in scope: data constructor `RemoteObject'
UDisksEvt/DBus.hs:49:11:
Not in scope: data constructor `RemoteObject'
UDisksEvt/DBus.hs:53:18: Not in scope: `mkClient'
UDisksEvt/DBus.hs:56:19: Not in scope: `mkClient'
make: *** [udisksevt] Erreur 1
Abandon...
ERROR: makepkg exited with an error (512)
It's weird, because I succeeded previously to build the 1.0-1 release after manual interventions, using also bauerbill.
At that time, I manually built/installed a haskell-parsec3 3.1 package and the haskell-dbus-core depending on it, before running 'bauerbill -S udisksevt'.
And that worked...
There is also another inconvenience with that package :
The build process needs to install temporarily many packages (especially haskell related), using more than 700M of disk space.
They are uninstalled at the end, but this is not very practical, when haskell is not used elsewhere on a machine...