Add patchbox-wifi to control wifi hotspot

[ozbenh]

Mostly moving things from pisound-btn, allowing wifi hotspot control
via systemd (and thus via the patchbox-cli) to work without pisound-btn

Signed-off-by: Benjamin Herrenschmidt benh@kernel.crashing.org

[ozbenh]

Updated: removed debian/conffiles, it appears debuild automatically picks up stuff installed in /etc and having them also listed in conffiles causes duplicates when doing dpkg -s patchbox-wifi. I prefer having it all in one place.

[gtrainavicius]

Hmm, I seem to hit an issue trying to uninstall patchbox-wifi. Here's what I do:

# Start with pisound-btn 1.14-1
sudo apt install pisound-btn=1.14-1

# First install the new packages:
sudo dpkg -i patchbox-wifi_1.0.0-1_all.deb pisound-btn.deb

# Then try to remove patchbox-wifi:
sudo apt remove patchbox-wifi

# I get dpkg-divert: error: rename involves overwriting '/etc/default/hostapd' with
# different file '/etc/default/hostapd.orig', not allowed

# The workaround for the bad state is:
sudo rm /etc/default/hostapd.orig
sudo apt -f install

[ozbenh]

Hrm... this happens while trying to remove the diversion. I don't fully understand how dpkg-divert works, I think what happens is that when patchbox-wifi takes over the diversion from pisound-btn, it's seen as "replacing" the file (you get the question about replacing a user modified config file if you don't use -y). Later, when trying to remove the diversion we end up with an error trying to replace a user-modified file with ours.

Any idea on your side how to better handle that ? I find debian packaging extremely complex and badly documented to be honest :-) (i'm more familiar with rpm but mostly I'm a kernel guy).

One option could be to simply not try to divert and override the config from a postinst of some sort, but that has its own drawbacks.

I wonder if dpkg "tracks" the override of the file before it runs the scripts that handle the diversion and gets confused...

[ozbenh]

Looks like a variant of this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363524

I'll play around and find a way to fix this

[ozbenh]

Allright, so I've reworked the diversions roughly based on https://wiki.debian.org/ConfigPackages using postinst/prerm and symlinks, which seems to work a lot better.

[gtrainavicius]

Indeed, this is working way better, will merge the pull requests now, thank you! :)

[ozbenh]

Thanks ! Are you going to update the binary packages in the repository ?

[gtrainavicius]

Yes, it's now available in 'beta' location, you can switch to it by editing /etc/apt/sources.list.d/blokas.list and changing the contents to this:

deb http://apt.blokas.io/beta/ rpi main

Could you give it a go and see if you can find any issues, especially around upgrading from pisound-btn=1.14-1?

It seems alright for me, if it's fine, I'll move it to the public location.

[ozbenh]

Will do. I tried updates from the older pisound locally but I'll do more tests

[gtrainavicius]

Great, let me know once you give it a go, and if all is fine, I'll move it to publicly released location. :)

[ozbenh]

Seems to work fine. I also tried a clean install + update.

By default apt-get upgrade will keep pisound-btn and patchbox as-is, ie, they will be "kept back" because of the change in dependencies. apt-get dist-upgrade will get the new versions however.

It might be worth cutting a new image to avoid surprises, that said, things seem to work either way.

[gtrainavicius]

Ugh, I wonder if there's some way to force it to get updated in the regular way (the simplicity for our users is key). One thing I forgot to do still is to make at least patchbox-cli to depend on the new patchbox-wifi package too.

The least we should do then is make sure that patchbox update command is able to correctly get the new package installed.

[ozbenh]

Well, there's also sudo apt --with-new-pkgs upgrade which brings in new dependencies but then nobody uses that ... (it might help if patchbox own "update" feature did, unless you are doing a dist-upgrade ? I didn't check and away from the machine right now..

[ozbenh]

So patchbox update doesn't actually update any package other than "patchbox" and "patchbox-cli" and from what I can tell "patchbox" is just an empty metapackage that depends on nothing other than patchbox-cli... ie. you don't actually update any other distro package as far as I can tell.

That said, we could do an update of patchbox-cli that updates the update.sh script which in turn gets a bit of logic to check if pisound-btn is installed, if it is, update it explicitly which will bring patchbox-wifi. Or we can try adding patchbox-wifi as a dependency of patchbox-cli. That might work with the existing update script since it's an explicit package update, not sure. We would have to try.

What's odd is that the github repo has patchbox-cli 1.3.1 but what's installed on my system is 1.3.2 ... how did you build it ? Also how does it get its version since none seems to be specified in debian/control ?

[ozbenh]

Note: This means that as it is today, patchbox cli "update" command won't update any pisound package either. You might want to consider making update.sh do sudo apt --with-new-pkgs upgrade to update everything in-place without removing anything (ie, not a dist-upgrade). With the current buster based image it won't update much anyways since it's stuck due to the rename to old-stable, meaning that unless the users also do:

sudo apt-get update -y --allow-releaseinfo-change --fix-missing

Nothing outside of your repos will get updated anyways

[ozbenh]

So I verified that adding patchbox-wifi (>= 1.0.0) to patchbox-cli dependency list seems to make patchbox-cli "update" function do the right thing indeed.

Do you want me to do a separate PR for that change ? How do I deal with versionning ? IE. the current git repo has 1.3.1 but the actual repo has 1.3.2 so I'm missing something here ... Also having the debian/ dir in github inside a "versionned" dir (ie patchbox-cli-1.3.1 in this case) means any update causes a big rename which makes reviews difficult.

Just let me know what you want me to do :-)

[ozbenh]

Another problem that needs fixing is that one of the patchbox 'modules' will fail when pisound-btn is not installed causing patchbox init service to fail. I need to fix that too

[ozbenh]

Do you have some documentation on the patchbox module stuff ? I feel like the right way to solve the problem here is to create a different patchbox "module" for pi-stomp (which is what I've been toying with) which is a copy of modep but doesn't use pisound-btn. What do you think ? IE. as is, I can remove pisound-btn and pisound-ctl and keep wifi, but the patchbox-init.service fails on boot because it tries to activate the modep module which depends on pisound-btn.service among others.

Do I understand correctly that a patchbox "module" is a set of services representing a use case of patchbox and there is always one module active ?

Additionally, in pisound-btn, the postinst script unconditionally re-enables the service, regardless of whether the current patchbox "module" wants it or not. In my case (pi-stomp) I really must not since it will conflict on the GPIO usage.

[gtrainavicius]

What's odd is that the github repo has patchbox-cli 1.3.1 but what's installed on my system is 1.3.2 ... how did you build it ? Also how does it get its version since none seems to be specified in debian/control ?

Thank you for noticing, I forgot to push the 1.3.2 version from one of my sd cards. :) Sorted it out.

Do you want me to do a separate PR for that change ? How do I deal with versionning ? IE. the current git repo has 1.3.1 but the actual repo has 1.3.2 so I'm missing something here ... Also having the debian/ dir in github inside a "versionned" dir (ie patchbox-cli-1.3.1 in this case) means any update causes a big rename which makes reviews difficult.

Yes, we'll have to update patchbox-cli too. It should depend on patchbox-wifi itself too. The folder name with the version embedded in it is actually an artifact from debhelper - it was some weird requirement to have the version in the name, and then to archive it too, so I wrote a build-deb.sh to workaround the archiving part. It sort of expects to have a tared version of the source code in parent folder, with version in the name. Some additionally shell scripting could work around that I guess, then it'd be unnecessary to git mv these folders. This same change should be applied across all build-deb.sh scripts in patchbox-os-debs and modep-debs repos.

Some info on Patchbox Modules is available here: https://blokas.io/patchbox-os/docs/modules/

The systemd services can be 'masked' (using mask command), patchbox-cli will ignore failures of starting masked services. This seems to be the purpose of the 'mask' command. :)

Got to run now, I hope this provides major bits of info, let me know what should I elaborate more on. :)

[ozbenh]

Ok, I'll try to update patchbox-cli. As for the masked services, the problem we've been having is that pisound-btn postinst script will unconditionally re-enable it, so whenever that package gets updated, the service gets unmasked and we get pisound-btn conflicting with our service for GPIO use...

That said, should the modep patchbox module made to not rely on pisound-btn ? Things like pistomp use modep but not pisound-btn, ideally they should be different things no ?

Either that or maybe make patchbox deal better with a service that doesn't exist at all (uninstalled)

[gtrainavicius]

If I remember right, the 'masked' status should persist, so even if pisound-btn postinst itself tries to reenable and start the service, the masking won't allow it, until the service is explicitly unmasked.

The reason MODEP depends on pisound-btn is because it sets up a couple of scripts for the Pisound's button, meant for controlling MODEP.

Could you try and see if masking pisound-btn would help in your case?

[ozbenh]

The pistomp installer masks pisound-btn, but it does get re-enabled on update or resinstall of the pisound-btn package unfortunately