Version 3.3-1 adds to the wrapper script first-run setup to make sure you have the current working soundcard selected in .asoundrc before AlsaTune opens for the first time, a handy GUI window opens with buttons activating the same "Test Tone" and "Soundcard" functions found in the main GUI for you to select and test, and also a "Volumeicon" button to reload the volumeicon applet (used in Vuu-do and some other Openbox distros) after making changes. And lastly a "Done" button to use after all changes have been made, that writes a marker file in ~/.local/share/alsatune to let the wrapper know first-run has already been done so no need for the setup GUI in the future, and then opens AlsaTune for you.

One odd thing I noticed - after testing it a couple times with loginctl, it no longer worked with pm-hibernate until after I rebooted.

so no issue here.

Another words getting dhcpcd installed.

Xfce cursor choice and size works fine

JMW gives me the choice and size set in .Xresources over terminal apps, but over desktop and gui apps drops to the small/default size. I've run out of internet howtos (all non-Devuan stuff).

I'm thinking this is a JWM thing, so anybody got any hints & tips on this one?

Sorry for the late response.

I am getting things setup to give it a try.

Will get back to you.

Source:
https://git.devuan.org/greenjeans/vuupaper-gtk2

Also used the chat bots to create this https://github.com/rations/NAMp/releases You can load multiple nam captures and change through them by turning the dial. It's supposed to be more like using a real amp. So if you capture the gain from 1 to 10, turning the dial is like turning the dial on a real amp. Or you can just load a folder of all different captures (up to 64).

There's a VST3 version for linux and windows but linux also gets a standalone version that is a VST3 and LV2 host.

I just switched to dkwm (https://bitbucket.org/natemaia/dk/src/master/), pretty good and light, it is really near bspwm. And I wanted to make my own bar to go with, I use this : https://github.com/fahmiirsyadk/ox. The bar is starting to look nice, but the problem is that the wm doesn't know there is a bar, so the windows are full screen (and go under the bar).

So my question is how does the wm know there is a bar and how to specfy the height ?

Thanks you

on a less uplifting note, i made a thread about shed on the freebsd forums and got no traction whatsoever, which i interpret as the BSD world having no interest in something like shed, yes i know FreeBSD isn't the only BSD DISTRO out there nor it represents the BSD side of unix and unix-like operating systems, tho i always got the impression that out of the different BSD distros FreeBSD was the one most interested in new software and new alternatives to ways in which things are done, so if they don't care i can only guess no one else in the BSD space will

which makes way for my decisions:

i will make no attempt at porting shed to any OS nor distro, i will keep writing in a portable manner as i've been doing until now, simply i will not make any effort nor collaborate first hand in code for porting shed to any specific OS nor distro, IF someone ever gets interested in the porting of shed i will take in any patch and merge any pull request

i will keep the development of shed with me, my uses and my preferences as the MAIN target and target audience of shed, which is to say the development of shed will keep assuming my setup first and foremost, not to say i will not care about issues reported by other nor that i will not care to implement features suggested or requested by others, simply that those will have a lot lower urgency and importance to anything that is essential to my usecase, also i will keep only testing shed on the distros i use mainly, which at the current time my main machine is a laptop on devuan 6 excalibur (stable) with elogind, sysvinit and xorg as the windowing server, the components entrailed on that setup are the ones i test and make sure work without issue first hand

i will only TRY to package shed for debian, i was thinking of not even packaging shed at all but i will make an attempt to package the next release of shed for debian, if i do succeed on creating a package and getting it accepted on debian so be it, if the package is rejected or i fail to create a package then so be it too, i will not try to package for any other distro after that

that's all for now, i do hope to have more positive news next time and to put out the next release of shed in august

the freebsd forum thead if anyone is interested: https://forums.freebsd.org/threads/shed … ng.103091/

p2papp: p2p chat, file sharing and remote command execution.

a ~300 LOC single file C app without runtime deps other than libc.

no compile time deps other than gcc. even C headers not needed.

IP filtered singleton one-to-one connection. no socket backlog.

p2pchat: This is a clone/fork of p2papp  with only one difference:

remote command execution logic completely stripped of. So more safe.

Here is the repo. please enjoy:  https://codeberg.org/postala/

"minimal GTK graphical login manager ... snip"

* user's login MUST not / never been breaks.

   pulling GTK isnt like minimal.

   GUI libs/frameworks depends/assumes too much little things;  its fagile, not safe at least.

   gtk needs already running/functional display server/compositor to present something.

   gui stuff may not even installed on given system. (Say container, server, or user (wants to) uninstall that gui libs  for some reason.)

   A newbie user may not repair broken login himself and/or dont know how to drop root console at boot.

   I see to much complaints about broken login caused by "login managers" on forums.

* So how about a self contained statically linked tui/gui app that cant depends anythink in system.

FYI: there are a handfull single file/header tui/gui stuffs on codeberg, github ...

I suspect we copied similar ideas around the web
for comparison

see man invoke-run(8) and /lib/runit/invoke-run script (instead of sourcing, it's an interpreter that exec into the run file)

in the runit Devuan/Debian package we ship /etc/sv/svlogd/run, same concept as yours (to be symlinked in each service's log dir)

and /lib/runit/finish-exec ;
usage examples for the above 3 are in services in the runit-services package.

Again I agree: in fact invoke-run and finish-exec supports printing start/stop messages, but you need to touch a flag file in /etc (/etc/runit/verbose)

Yes it's of interest I'll see if this can be included in runit-services; getting network right for distribution is not that easy because you
have to account for different setups (sometimes in conflict/not compatible with each other); in case, is it ok if I
credit you as 'freem' (do you want ot add an address - beware the spam-  or a full name?) ?

Now about udev/eudev: the main problem is that it has to be started early at boot (as a oneshot, when the supervision tree is not active yet).
So, in order to supervise it in a run script we need to stop it and restart it inside the runit service; I saw this done in Void, not sure if ther are races during startup.
Do you start udevd early during boot , then  stop it and restart it in the runscript? If yes, are there any issues such as races due to udev not being up when the supervision tree starts all services? Do you have any runit service that depends on udevd?

Also, there is the same problem at shutdown; usually udevd is stoped very late during shutdown (later than other services); I'm not sure this is actually necessary, because, in theory, I think, we don't need to react on devices event at shutdown. But I'm not sure if it creates problems to shutdown without udevd running; again do you observe any issues, such as an unclean shutdown?
Issues with filesystem at next boot?

Best, Lorenzo