Le 24/04/2019 à 00:24, Steve Litt a écrit :
On Tue, 23 Apr 2019 12:22:44 +0200
Didier Kryn <k...@in2p3.fr> wrote:

    Hello Devuaneers.

    I have put on https://git.devuan.org/kryn/hopman an application
to let mount/umount/open filesystems on hotplug mass storage devises
such as USB sticks or SD cards. This is a replacements for features
provided by Desktop Environments.
[snip]

OUT-standing!!!!

I didn't have a ready to use Devuan VM, so I just installed it on Void
Linux. It worked perfectly, once I understood the deal.

A lot of the stuff I report here might not happen on Devuan, but then
again I might find some errors or maloptimizations that might be edge
cases in Devuan.

Anyway, I followed your compile instructions and it worked perfectly.
But when I ran hopman, I got a "Bus error" message running it as either
slitt or root. So I touched /home/slitt/.hopmanrc, got past the bus
error, but got another error. Infatiguable, I copied the entirety
of /etc/default/hopmanrc to ~/.hopmanrc, and the thing began to work.


    I didn't try to link it against musl libc yet. Thanksfor doing it. Many C library functions are non-standard in glibc and the application might well rely on some non-standard behaviour. Or there might just be a bigger bug. Reading config file is done by mmap()ing it and then there's some realloc()  stuff to store the data.


For those of you who haven't tried hopman yet, let me define "work".
You run hopman on the command line, and it sits there and spins. No
gui. *Until* you insert a thumb drive. Then, all of a sudden, the gui
pops up with the thumb's label. Left click the label line and you get
choices to open in filemanager, open in terminal, mount, or eject.
Regardless of what you set EjectHelper to in .hopmanrc, trying to eject
always errors saying "No command helper". This is true even if I set
the EjectHelper to the same string as UmountHelper in ~/.hopmanrc. I
have a hunch something's hard coded that shouldn't be. One of the source
files (config.c I think) mentions there's no known EjectHelper.


    Yes, I have hardcoded it before I developped the configuration capabilities. I should remove this hard-coding.



Hopman didn't show up anywhere on my lxpanel: I have a feeling that was
a design decision so hopman doesn't need to know the intracies of each
panel it interfaces with.


    I don't know how to do that, and didn't think of it even. I guess this is standardized in Freedesktop -- not everything is bad in Freedesktop.


Bottom line, a running Hopman shows a GUI window *only* if thumb drives
or USB harddisks are plugged in.

Like almost every other mounter software, hopman gets itself in a crazy
state if you yank the thumb drive out before unmounting it. In this
crazy state, it tells you you can't unmount it because it's in use.


    That shouldn't happen. Hopman could only tell you it is not mounted. Or it is just the error reported by pumount. And pumount will probably report it because you still have the mountpoint in use in a terminal or file manager or any other application.

Anyway the mountpoint shouldn't be reported anymore by the kernel in /proc/self/mountinfo, and hopman checks this file every 5s (by default) and will report it is not mounted.

This also happened on my inotifywait based mounter (which another
Devuanner improved substantially). I'll research this more.

I'm trying to create a runit run file for hopman and am having a little
trouble. I'll report back later.


    hopman isn't a system-wide daemon. It should rather be considered a login session daemon; it runs for a user. Are you using runit to launch your session's daemons? I think the session daemons can be declared in the DE's configuration.


One more thing: Hopman is wonderful software. Very few dependencies,
easy as hell to compile. No ./configure step. No BS. The source is
fairly easy to read. It does one thing and does it well. This is how
all software should be written.

    Thanks Steve. That was the goal; these are the principle we all share at Devuan (~:

        Didier





_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Reply via email to