Re: [DNG] New application ready to test: hopman
On 1/5/19 18:23, aitor_czr wrote: What about the use of CMake? I can help on that, and also in the translations. Aitor. using xgettext and msginit ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
Il giorno mercoledì 24/04/2019 01:24:09 +1000 wirelessd...@gmail.com ha scritto: > > On 24 Apr 2019, at 01:06, Didier Kryn wrote: > > > >> Le 23/04/2019 à 13:22, Edward Bartolo via Dng a écrit : > >> Making it a Debian package should be easy. Use dh_make to create a [snip] > May I suggest looking at this reference? Apologies if you have already seen > it. > > https://www.debian.org/doc/manuals/maint-guide/dother.en.html [snip] Hi Let me suggest also this tutorial last updated 2019-03-13: https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf Regards -- al3xu5 Say NO to copyright, patents, trademarks and any industrial design restrictions. Public GPG/PGP key block ID: 4096 bit RSA key 69C5977BF94CFE23 Fingerprint: 59C6 9DC7 CD4B CF2F A190 E3DE 69C5 977B F94C FE23 pgpymNv0AvFsJ.pgp Description: Firma digitale OpenPGP ___ 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 Fri, 26 Apr 2019 12:11:02 +0200 Didier Kryn wrote: > 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] > > > > > 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. > > > Hardcode has been removed. You can now specify a command to > eject the device, if you know of one. > > > > > 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. > > This is solved as well. It was enough to add one line in the > launcher file. > > Didier I completely removed all traces of hopman, then did another git clone and compiled and installed it. Now: * It runs perfectly without a ~/.hopmanrc * Items in ~/.hopmanrc override/add to items in /etc/default/hopmanrc - Which in my opinion is the best way to do things * The Eject option appears every time, regardless of mount status - I think this is best - Don't second guess mount and insertion state * Eject runs whatever program specified in /etc/default/hopman - Or ~/.hopmanrc - I got it to run Gnumeric :-) * It did not put an icon in the system tray of any panels I tried: - Not lxpanel - Not xfce4-panel - Not vala-panel - Not tint2 A few words about the panel's system tray: xfce4-panel had no provision for a system tray that I could see. My machine uses Openbox as its WMDE (Window Manager/Desktop Environment). I was running the panels as an afterthought, so I'm would not be surprised their system trays are working wrong. A few words about priorities... Those of us who don't run panels (Openbox, fluxbox, twm, ctwm, etc) need to be able to locate the currently running hopman's window very fast. This could be done by adding the following options in ~/.hopmanrc: * no_window_decorations=boolean (default false) * window_background=color (default wmde default) * window_foreground=color (default wmde default) * strongarm_window_position=y,x (default no strongarm) The preceding defaults make it just like it is today, but if I wanted to I could have the hopman window appear without titlebar and border, orange on green, in the upper right corner, which would make it *much* easier to quickly locate. If you do this, I suggest you change the program so that right click, instead of duplicating left click, issues a pull up menu about hopman itself, including whether to decorate or not. The decorate-or-not thing might be impossible in any practical sense, if the wmde doesn't expose the window parameters to the application. As a no-panel type of guy, my top priority would be the ability to put the hopman window in a specific place, so I can look there as I alt+tab around the windows. With such placement, coloration and decoration choices wouldn't be essential. Some thought should be given to whether you want the hopman window to appear whether or not there are mountable removable drives. There are pros and cons to both sides. This is a great program that makes my life easier. I've put /bin/hopman in my ~/.xinitrc, and might figure out a way later to make it respawnable so it's always with me. Thanks, and feel free to ask me any questions. SteveT ___ 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] 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. Hardcode has been removed. You can now specify a command to eject the device, if you know of one. 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. This is solved as well. It was enough to add one line in the launcher file. 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 à 00:24, Steve Litt a écrit : 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 reproduce, but have partly rewritten the logic for looking at config file and eventually using built-in. I hope it won't crash anymore. And it will better log what it is doing. Just pushed the changes a minute ago. 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 à 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] 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
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
Re: [DNG] New application ready to test: hopman
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. 2. Either gracefully treat a packing rc dir or to create it automatically or just to have a good stderr message 3. Document the misbehaviour when users... Misbehave (okay, that was a bad joke). I think, 1 and 2 are easily actionable and, from what you described, would greatly improve the UX. 3 may be trickier. -- Evilham___ 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 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. SteveT ___ 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 24 Apr 2019, at 01:06, Didier Kryn wrote: > >> Le 23/04/2019 à 13:22, Edward Bartolo via Dng a écrit : >> Making it a Debian package should be easy. Use dh_make to create a >> 'debian' subdirectory with the necessary Debian control files. Then, >> when that is ready build the debian packages using 'gbp buildpackage'. >> Both commands should be run in the source's top directory. > > > Thanks Edward. > > ' gbp buildpackage' fails because hopman-1.0 isnot a git directory. The > git directory is actually one level higher in my case. > > I need a method not relying on git. > > Here is what I tried before. dh_make works fine, no problem with it. > > Then I tried dpkg-buildpackage but it failed (I don'tremember for sure > why, maybe because of the absence of a gpg signature). > > Then I tried 'debuild -us -uc' and it did produce a .deb file with the > amd64 extension in the name, which is what I expected, but, when I installed > the package with 'dpkg -i', it installed a few files which are present in all > debian packages, but none of the usefull files this package should provide > (executable, manpage, config file, icon and launcher). > > The matter is rather complicated and I only tried recipes :~) > > Didier May I suggest looking at this reference? Apologies if you have already seen it. https://www.debian.org/doc/manuals/maint-guide/dother.en.html It lists the various files under the debian/ directory and what they are used for. Eg. Installing manpages, init scripts, readme, creating symlinks on install, pre/postinst, etc. I am using the command “dpkg-buildpackage -us -uc -i -I” for building the packages. Also using regular “dch” for the changelog as my git repository is not in the required “debian format” for “gbp”. HTH —Tom___ 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 23/04/2019 à 13:22, Edward Bartolo via Dng a écrit : Making it a Debian package should be easy. Use dh_make to create a 'debian' subdirectory with the necessary Debian control files. Then, when that is ready build the debian packages using 'gbp buildpackage'. Both commands should be run in the source's top directory. Thanks Edward. ' gbp buildpackage' fails because hopman-1.0 isnot a git directory. The git directory is actually one level higher in my case. I need a method not relying on git. Here is what I tried before. dh_make works fine, no problem with it. Then I tried dpkg-buildpackage but it failed (I don'tremember for sure why, maybe because of the absence of a gpg signature). Then I tried 'debuild -us -uc' and it did produce a .deb file with the amd64 extension in the name, which is what I expected, but, when I installed the package with 'dpkg -i', it installed a few files which are present in all debian packages, but none of the usefull files this package should provide (executable, manpage, config file, icon and launcher). The matter is rather complicated and I only tried recipes :~) 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
On 4/23/19 2:22 PM, Edward Bartolo via Dng wrote: > Making it a Debian package should be easy. Use dh_make to create a > 'debian' subdirectory with the necessary Debian control files. Then, > when that is ready build the debian packages using 'gbp buildpackage'. > Both commands should be run in the source's top directory. also in a similar situation and could use some help with debian packaging for git.devuan.org. not a dev really, just trying to make some packages work without-f*ckin-systemd. so thanks for that, will try it out. d. signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] New application ready to test: hopman
Making it a Debian package should be easy. Use dh_make to create a 'debian' subdirectory with the necessary Debian control files. Then, when that is ready build the debian packages using 'gbp buildpackage'. Both commands should be run in the source's top directory. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New application ready to test: hopman
Didier Kryn writes: 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. It only depends on a linux kernel version newer than 2.2.26 and the GTK+-2 library, plus helper commands to mount/umount/open the filesystems, such as pmount/pumount, thunar and xfce4-terminal. That's great, thank you. The git repository contains a description of the project, plus a directory containing the source and makefiles. To instal: git-clone the project, then: cd hopman/hopman-1.0 make && make install # You must be root to install make cleanall Installed files: /usr/bin/hopman, /etc/default/hopmanrc, /usr/share/man/man8/hopman.8.gz,, /usr/share/pixmap/hopman.png, /usr/share/applications/hopman.desktop I tried to make it a Debian package, but with little success. I need help for that. I hope someone can devote some time to help with this. I also need help to remove from the gitlab a previous, primitive version which was named partmon. I transfered that repository to my user on gdo and if there are no complains I'll delete it in a couple weeks, I hope that's acceptable. -- Evilham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] New application ready to test: hopman
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. It only depends on a linux kernel version newer than 2.2.26 and the GTK+-2 library, plus helper commands to mount/umount/open the filesystems, such as pmount/pumount, thunar and xfce4-terminal. The git repository contains a description of the project, plus a directory containing the source and makefiles. To instal: git-clone the project, then: cd hopman/hopman-1.0 make && make install # You must be root to install make cleanall Installed files: /usr/bin/hopman, /etc/default/hopmanrc, /usr/share/man/man8/hopman.8.gz,, /usr/share/pixmap/hopman.png, /usr/share/applications/hopman.desktop I tried to make it a Debian package, but with little success. I need help for that. I also need help to remove from the gitlab a previous, primitive version which was named partmon. Thanks. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
