Re: [DNG] New application ready to test: hopman
Le 24/04/2019 à 20:43, Steve Litt a écrit : On Wed, 24 Apr 2019 09:05:12 +0200 Didier Kryn wrote: Le 24/04/2019 à 01:05, Evilham via Dng a écrit : Am 24. April 2019 00:24:56 MESZ schrieb Steve Litt 3. Document the misbehaviour when users... Misbehave (okay, that was a bad joke). There's an infinite number of ways a human can misbehave. For brutal extraction of the media, I don't think it is easy to characterize. There's a way. There can be a "superumount" that acquires a root password and keeps doing umount until it's really unmounted on all lists like mtab. /etc/mtab is userspace only and is optionaly bypassed by mount; it's unreliable. Two pseudofiles are maintained by the kernel: /proc/self/mounts and /proc/self/mountinfo. The last is also the newest and contains more information; this is the one which is checked periodically by hopman. You can perfectly verify this by invoking pmount/pumount from the command-line while looking at hopman's display. The periodicity of these checks is set in the config file; it is 5s by default. Hopman does not rely on its interactions with the user to know the status of the filesystems; instead it reads all it shows from /dev, /sys and /proc. After a mount or umount command has been selected in the menu, then, of course, hopman doesn't wait 5s to check the result, but it shows only what the kernel reports. When you select unmount on hopman's menu, hopman invokes pumount, and pumount eventually calls umount(). If some process is accessing the mount point or any file or directory in the directory tree below the mountpoint, umount() returns -1 and sets errno to EBUSY (man 2 umount). At this point, I guess pumount prints strerror(errno) which is equal to "Device or resource busy". Then hopman detects that pumount exited with an eror code and hopman reads the message that pumount has printed on its stderr and shows it in a pop-up window. But hopman does not devise the existence or status of partitions from the result of pumount or any helper command. I am surprised that you can select unmount on hopman's menu for a partition on a device which has been removed, because the hotplugger should have deleted the corresponding device file and, therefore, hopman should have removed it immediately from its display. Did you open the menu and then extract the device before clicking the menu entry ? Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Cease battling each other in e-mail
On 24/04/2019 19:11, Rick Moen wrote: > I waited a day, before commenting about this, because I needed to ponder > the matter carefully and not seem as if I were taking sides in > intra-Devuan Project interpersonal warfare. > > Jaromil, I was extremely serious when I said you-all caretakers should > convince each other to _cease battling each other in e-mail_. The only > result is angry resignations, which is about as useful to an open source > project as sawing off your own arm. > > Cease battling each other in e-mail. Jesus Jehosephat Christ, man, > isn't the wisdom of that advice clear _yet_? > > All of you, your good self, Enzo/KatolaZ, Dan Reurich, Ralph Ronnquist, > Evilham, golinux (who's been constructive and blameless as always), > fsmithred, and others I'm probably forgetting, should be acting to end > the interpersonal craziness. Nobody should be forced out, nobody should > be driven to quit, everyone who's leaving in anger should be invited to > a Jitsi conference where you figure out how to bury the hatchet and > come up with a more-constructive way of resolving disputes. (I'm > aware that extremely bad things are happening in private communications. > IMO, you should be working nonstop to not only stop but reverse those > things.) Very well said. The kind of bickering that has been occurring here is, quite clearly, damaging the project. It seems to me as an observer of this project that the bickering is in fact more damaging to the project than any of the contentious actions that have occurred! It would be better by far to JUST STOP the bickering. It shouldn't even be necessary for anyone to issue apologies (although no harm in doing so, and I note that there already have been apologies). But even without apologies, just stop. Draw a mental line under everything that has happened and go on. There is no doubting the technical capabilities of everyone involved and the importance of this project to operating system diversity. > The Jenkins server thing? [...] Treat it as a minor organisational-process > bobble that took > down an important system. Use the event as an opportunity to make sure > you have working failover plans. [...] > The people / communication problems you and > the other caretakers have been failing to solve are an, frankly, an > emergency. Yes, in addition to putting in place some technical plans for emergencies, resiliency and planned maintenance, it also seems to be important to put in place procedures for *communication* between participants (with logging for future reference). There need to be reliable and documented ways to let everyone involved (as well as the public when a public-facing service is affected) know what is happening, including in emergencies. If anything, recent events should be seen as a positive opportunity to get this sort of structure that will inevitably be needed for growth, resiliency and success in place. > Dismiss the circular firing squad, sir. Good phraseology. -- Mark Rousell ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
On Wed, 24 Apr 2019 09:05:12 +0200 Didier Kryn wrote: > Le 24/04/2019 à 01:05, Evilham via Dng a écrit : > > Am 24. April 2019 00:24:56 MESZ schrieb Steve Litt > > 3. Document the misbehaviour when users... Misbehave (okay, that > > was a bad joke). > > There's an infinite number of ways a human can misbehave. For > brutal extraction of the media, I don't think it is easy to > characterize. There's a way. There can be a "superumount" that acquires a root password and keeps doing umount until it's really unmounted on all lists like mtab. SteveT Steve Litt January 2019 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Cease battling each other in e-mail (was: Of confidence and support and the future of Devuan.)
Quoting Jaromil (jaro...@dyne.org): > Precisely. I am afraid though, that people will just go on writing > "please stay <3" letters to CenturionDan, (who is the one responsible > for Katolaz to leave, for the CI for being down, for this drama here) > without even thinking how other volunteers feel like. Because this is > how politics work: personalisations, egos and populism. I waited a day, before commenting about this, because I needed to ponder the matter carefully and not seem as if I were taking sides in intra-Devuan Project interpersonal warfare. Jaromil, I was extremely serious when I said you-all caretakers should convince each other to _cease battling each other in e-mail_. The only result is angry resignations, which is about as useful to an open source project as sawing off your own arm. Cease battling each other in e-mail. Jesus Jehosephat Christ, man, isn't the wisdom of that advice clear _yet_? All of you, your good self, Enzo/KatolaZ, Dan Reurich, Ralph Ronnquist, Evilham, golinux (who's been constructive and blameless as always), fsmithred, and others I'm probably forgetting, should be acting to end the interpersonal craziness. Nobody should be forced out, nobody should be driven to quit, everyone who's leaving in anger should be invited to a Jitsi conference where you figure out how to bury the hatchet and come up with a more-constructive way of resolving disputes. (I'm aware that extremely bad things are happening in private communications. IMO, you should be working nonstop to not only stop but reverse those things.) The Jenkins server thing? That was an annoying technical failure, but did not in any way justify your firebreathing public and private e-mails. Treat it as a minor organisational-process bobble that took down an important system. Use the event as an opportunity to make sure you have working failover plans. I've built and administered Jenkins servers, most recently on remote-hosted VMs on AWS where failure of a new kernel to boot would have been deeply problematic. OK, so that happened. This is where you not only stand up a new Jenkins instance (if necessary, reconstructing it from scratch) but also make sure daily offsite scripted backups occur plus that you have the ability to quickly deploy a replacement host and restore state. At that point, any similar incident can be dealt with by using that recovery plan and then repointing DNS. I'm only a friendly outsider, but can say as a senior sysadmin and professional Operations person that the ci.devuan.org thing was not something to get angry and start threatening people over, no matter how many older grudges you've been holding. The infrastructure is important but only a small problem. The people / communication problems you and the other caretakers have been failing to solve are an, frankly, an emergency. Dismiss the circular firing squad, sir. Get everyone to come back onto Jitsi at some mutually convenient time, and talk things out. And cease battling each other in e-mail. Now. Oh, and I cannot resist sounding very non-American for a moment: You're deeply mistaken in deploring 'politics'. Politics is good! Politics, from the Greek Πολιτικά, means conducting the public's business. All software projects have politics, and the mature raction to that fact is not to recoil from it and call it base and evil, but rather to embrace it. Politics is part of the process of collective action, of getting things done. Populism? Egos? Personalisation? Sure. Those happen, and are part of the carnival, because there are human beings involved, and so one must be aware of those basic facts and swim through them, keeping on eye on what is actually the agenda. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [devuan-dev] Of confidence and support and the future of Devuan.
As a Devuan user I suggest the Devuan Administrative Team to consider the thinking of a detailed contingency plan in case of a crises that should include how to deal with internal conflicts and what to do when important servers fail. I would also suggest setting up emergency supplimentary servers that should stay dormant when there are no problems. By servers I do not mean those extremely expensive servers but also normal home computers. Furthermore, why not use virtualisation for these all important servers? In case a virtual machine breaks another instance should spring into life to replace it. These are my suggestions: I admit I am not at all versed where servers are involved let alone their adminstration. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Of confidence and support and the future of Devuan.
On 24-04-19 09:20, Jaromil wrote: > On Tue, 23 Apr 2019, KatolaZ wrote: > >> Counting individual contributions to a voluntary project is totally >> pointless: since there is no price tag on "one hour of voluntary >> work", then a voluntary contribution of one hour is as important and >> as valuable as 1000 hours of voluntary contribution. Noone can ask a >> volunteer to work more, or to work less, or to work at all, because a >> volunteer is a free man/woman devoted to a cause. Devuan is made by a >> community of voluntaries, not by single egos. Making contributions as >> much as possible *invisible*, anonymising, hiding, de-personalising, >> collectivising, this is the only way through IMHO, the only way to let >> a community shine. If anything will last, it will be Devuan as a >> whole, not any of the volunteers who have put it into existence. >> >> "A leader is best >> When people barely know he exists >> Of a good leader, who talks little, >> When his work is done, his aim fulfilled, >> They will say, 'We did this ourselves.' >> ", Lao Tzu, Tao Te Ching > Precisely. I am afraid though, that people will just go on writing > "please stay <3" letters to CenturionDan, (who is the one responsible > for Katolaz to leave, for the CI for being down, for this drama here) > without even thinking how other volunteers feel like. Because this is > how politics work: personalisations, egos and populism. > > ciao Measuring the value of contributions from people to Devuan is not your strongest point. Besides there is only one person responsible for Katolaz to leave and that is Katolaz himself. Grtz Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [devuan-dev] Of confidence and support and the future of Devuan.
On Tue, 23 Apr 2019, KatolaZ wrote: > Counting individual contributions to a voluntary project is totally > pointless: since there is no price tag on "one hour of voluntary > work", then a voluntary contribution of one hour is as important and > as valuable as 1000 hours of voluntary contribution. Noone can ask a > volunteer to work more, or to work less, or to work at all, because a > volunteer is a free man/woman devoted to a cause. Devuan is made by a > community of voluntaries, not by single egos. Making contributions as > much as possible *invisible*, anonymising, hiding, de-personalising, > collectivising, this is the only way through IMHO, the only way to let > a community shine. If anything will last, it will be Devuan as a > whole, not any of the volunteers who have put it into existence. > > "A leader is best > When people barely know he exists > Of a good leader, who talks little, > When his work is done, his aim fulfilled, > They will say, 'We did this ourselves.' > ", Lao Tzu, Tao Te Ching Precisely. I am afraid though, that people will just go on writing "please stay <3" letters to CenturionDan, (who is the one responsible for Katolaz to leave, for the CI for being down, for this drama here) without even thinking how other volunteers feel like. Because this is how politics work: personalisations, egos and populism. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
Le 24/04/2019 à 00:24, Steve Litt a écrit : On Tue, 23 Apr 2019 12:22:44 +0200 Didier Kryn 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
Re: [DNG] New application ready to test: hopman
Le 24/04/2019 à 01:05, Evilham via Dng a écrit : Am 24. April 2019 00:24:56 MESZ schrieb Steve Litt : >On Tue, 23 Apr 2019 12:22:44 +0200 >Didier Kryn 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. > >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. > >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. > >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. >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. > >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. > Thank you for the review! I had the feeling this would be quite nice :-). If I may recommend, open 3 issues on gdo (on phone, about to sleep, else I'd do it): 1. Improve documentation / UX by communicating the "No GUI until you plug sth" behaviour on stdout. It might print a message on stderr (all messages are sent to stderr, except by error of the author), however one can read in the man page that "Hopman shows a list of hotplug (removable) mass storage partitions; it is invisible when there is no hot-plug partition." 2. Either gracefully treat a packing rc dir or to create it automatically or just to have a good stderr message Please excuse me evilham, I don't know what is a "packing rc dir". 3. Document the misbehaviour when users... Misbehave (okay, that was a bad joke). There's an infinite number of ways a human can misbehave. For brutal extraction of the media, I don't think it is easy to characterize. Thanks. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
