Would it be ok to move the wifi hostpot related config files to a separate package ? At the moment
they are part of debian/ of pisound-btn, which makes removing it trickier when using Patchbox without a pisound card.
Yes, it was historically there since very early versions when we only had the pisound-btn package. 
You may change it as necessary on your system, weāll note down to change this once weāll be working on updating the OS image.
If youād do a pull request for this, we could publish the new packages on our apt.
Sure, happy to do a PR but I donāt know how to do one for a ānew packageā since it would be effectively a new repo wouldnāt it ? I can just publish it on my github and let you clone it. Iāll look into it, thanks
I think it would fit nicely into this repo:
Maybe it could be called patchbox-wifi?
As itās a small package, it could be done similar to blokas-jack package, where the source itself is contained within the patchbox-os-debs repo.
So Iām working on this now (bear with me Iām new to Debian packagingā¦). I did hit a small snag:
In order for things not to break existing setup on apt-get update, what I would ideally need to do (based on instructions in PackageTransition - Debian Wiki case #8) is make the new version of pisound-btn depend on the ānewā patchbox-wifi.
However, that introduces a dependency between pisound and patchbox which didnāt exist before. Ie, pisound-btn could previously be installed on its own without any patchbox related stuff.
Is that ok ?
Yes, thatās ok - pisound-btn package as well as the rest of our .deb packages are all hosted on our own apt.blokas.io server, so itās fine for them to depend on each other for both Patchbox OS users and Raspberry Pi OS users (the apt server is set up as part of the install-pisound.sh script that users run to set it up)
Allright, found some time ā¦ gosh deb packages are ā¦ complicated. Iām mostly getting there. One issue thoughā¦
What to do with the scripts ? ie. enable/disable_wifi_hotspot.sh ā¦
The .service file in the package refers to them, they are somewhat pisound specific at the moment as they get āgit pulledā at postinst (which is ā¦ weird in itself, packages should be self contained).
I could/should move them into patchbox-wifi (and to a different location). This would probably work fine since patchbox-cli uses systemctl and doesnāt refer to them directly.
Iām thinking of creating a /usr/lib/patchbox/scripts.
The main issue is I can probably not move common.sh into it as we are getting back into rather pisound specific territory. That would mean taking out the LED stuff from those scripts.
Any better idea ?
One option could be to include common.sh if it exists, and have a fallback dummy flash_leds if not.
Whatās your preference ?
So Iāve tentatively pushed my current work to:
GitHub - ozbenh/pisound: pisound kernel module and user-mode button branch patchbox-wifi
GitHub - ozbenh/patchbox-os-debs: Debian packages used in Patchbox OS image branch patchbox-wifi
For you to have a look and maybe test on an actual pisound system as I donāt have one before I do a PR (or if you want Iāll just do a PR and you can take it from there).
I probably need to polish the package descriptions/copyright/etcā¦ still anyways.
The basic idea is we have two new packages:
-
patchbox-common has /usr/lib/patchbox/scripts/common.sh (and possibly more in the future). This is the ānewā common.sh aimed at replacing the one in pisound. It will include a leds_common.sh provided by pisound if present otherwise provides stub LED functions. I havenāt yet changed the remaining scripts in pisound to use it, so the old one is still provided by pisound in the old location.
-
patchbox-wifi has all the wifi hotspot bits and pieces and some tweaks to take over the /etc/default/hostapd diversion from pisound-btn
Additionally pisound-btn is updated to 1.15, depends on patchbox-wifi and patchbox-wifi conflicts with pisound-btn < 1.15
Let me know what you think
1 Like
Sorry for not getting back earlier, we just had 2 public holidays here in Lithuania. Thank you for providing the GitHub repos, Iāll try it out soon and get back to you.
Ah no worries, I hope you enjoyed the break !
I think it would make sense to keep the ācommon and LEDsā logic entirely in the pisound-btn package, and donāt refer to it from the new patchbox-wifi package at all (including common.sh).
Instead, the enable_wifi_hotspot.sh and disable_wifi_hotspot.sh on pisound-btn side should do the LED logic part, and in the middle of that, just invoke the new enable_wifi_hotspot.sh and disable_wifi_hotspot.sh from the new patchbox-wifi package, to do all the WiFi hotspot logic.
Thereās also toggle_wifi_hotspot.sh script on pisound-btn side which accesses systemd service directly - itād be great to instead add a helper script in patchbox-wifi, called wifi_hotspot_status.sh or similar, to query the current state, and do the appropriate toggling logic.
Itās important to have both enable_wifi_hotspot.sh, disable_wifi_hotspot.sh in pisound-btn's script folder, as the scripts at /usr/local/pisound/scripts/pisound-btn are getting listed in pisound-config for remapping the button actions.
So in a nutshell, Iād propose dropping patchbox-common package, move out all the logic of WiFi .service and scripts to the new patchbox-wifi package, as you did already. Then change existing enable_wifi_hotspot.sh, disable_wifi_hotspot.sh, toggle_wifi_hotspot.sh scripts on pisound-btn to just keep the LED logic and invoke the patchbox-wifi scripts, abstract out any direct access to systemd calls on wifi-hotspot service with additional utility scripts.
I noticed enable hostspot restarts touchosc2midi, but disable hotspot doesnāt (so after disable hotspot, that service ends up failed).
I donāt know much about touchosc2midi but this seems ā¦ wrong.
What do you reckon should happen here ?
Iām not sure why you want to abstract from systemd ā¦ I find it rather cleaner to have the hostpot be a systemd service. Thatās also how patchbox-cli uses it.
If I do what you asked, patchbox-cli will no longer toggle the LEDs, is that what you expect ? Iām fine with it personally In fact Iāve started doing the changes, I just want to make sure we agree on the approach.
To clarify, with what Iām doing, patchbox-wifi provides scripts that are only meant to be used via systemd and systemd is the way to start/stop/query the hotspot. This is what āpatchbox-cliā will do (and what other non-pisound things are doing).
So I donāt see how wifi_hotspot_status.sh would fit in that picture, unless itās just a pisound-btn script, in which case it may as well be part of toggle_wifi_hotspot.sh
Iāve updated to two branches above in github with my changes. It includes a wifi_hotspot_status.sh in pisoundās scripts/pisound-btn that is used by toggle_wifi_hotspot.sh.
For the āabstractionā I decided to go for patchbox-cli ā¦ enable/disable just call the corresponding patchbox cli command. For status, I have that implemented but commented out, and use a shortcut
to systemd simply because loading patchbox cli for a simple status query is slow, and I donāt know
if you may want to āpollā that script in the future from pisound for other reasons, but feel free to
revert to the cleaner abstraction
Youāre totally right! I was thinking about this a bit wrong before. 
Btw, in the latest repo state, the /usr/lib/patchbox-wifi/enable_wifi_hotspot.sh and disable scripts are missing in patchbox-wifi.
Anyway, youāre right about using systemd to control wifi-hotspot, and thereās no need to introduce dependencies then on patchbox-cli for Pisound, as the button scripts could just work by enabling, disabling and checking the status current status for toggle.
I think itās fine for the LEDs to blink only when the wifi-hotspot state is being changed using the Pisoundās button.
Could you finalize this by making pisound-btn use systemd to control the WiFi, depend on patchbox-wifi package, and make sure the .sh files are commited to patchbox-wifi?
Done. Iāve also done a PR on github !
Added some comments to Pisoundās PR