debian packaging and service file

[x37v]

to build on bookworm I also needed to change the libmonome cmake_minimum_required VERSION to 3.25, I have that in a PR over there.

[artfwo]

Hi! Debian packaging files should not be a part of this source tree for several reasons, one being that we have to maintain Debian packaging afterwards and we might not always have the resources to keep it up-to-date with recent Debian policies.

Second, because of various Debian policy conflicts (i.e. avoiding static linking), any potential effort to push the package for serialosc into Debian would mean rewriting the packaging, possibly even without CPack or generated shell scripts in debian/, creating additional effort for the distro maintainers to repackage it (also see https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source).

Building this on Debian also requires installation of the whole package building environment, rather than just source dependencies. A package is generally useful, when it's used as a binary (FIY I have a semi-official Ubuntu PPA for serialosc that also provides binaries, those used to work great on Debian, have you seen https://launchpad.net/~artfwo/+archive/ubuntu/monome ?).

If you would like to have an official Debian package for serialosc, I'd suggest going through the Debian packaging guide and offer it for inclusion into Debian via Debian Mentors resource.

[tehn]

Hi Artem and Alex,

For background, Alex is trying to facilitate serialosc ease of inclusion in Cycling74's RNBO image for raspberry pi, so it's a similar use case to norns.

I believe the primary goal was to have a systemd unit easily installable in addition to a .deb package.

What is your suggestion for packaging up a systemd service?

[artfwo]

Hi Brian, Alex!

It depends on how the image is built in the first place.

Probably the easiest way for most cases would be to install both libmonome and serialosc from the aforementioned PPA; last time I tried the packages on an RPi they worked fine (PPAs provide build infrastructure for ARM64 and ARMHF). Those packages already provide a systemd service configured to run at startup and to keep the device configuration files under /var/lib/serialosc. Debian packaging for them is hosted at the PPA in the form of .debian.tar.gz archive and can be fetched with dget tool from Debian devscripts as follows:

dget https://launchpad.net/~artfwo/+archive/ubuntu/monome/+sourcefiles/libmonome/1.4.6-0ubuntu2~jammy1/libmonome_1.4.6-0ubuntu2~jammy1.dsc

Alex, if you'd still like to roll your own package for this project, PPA is one way to host it, other is Git (e.g. similar to how Debian git is setup), or whatever other infrastructure you might have for building the RNBO image, or the all-in Debian package upload process of course.

For the reasons explained above I'd rather avoid having any distro-specific packaging in this repo, including the CMake scripts. If necessary those can be easily patched for packaging with debian/patches (quilt), so the patches are cleanly applied and removed before and after building the package.

[x37v]

We have our own apt repo that we setup with an image we provide so the distribution is not an issue for us. Using an ubuntu PPA built for another distro feels a bit sketchy to me and ends up requiring quite a lot of extra deps (200+ to just get dget) so I'm not sure I'd go that route for our users.

I may end up just managing my own fork for our purposes but I'm curious if you have your .deb packaging setup shared somewhere?

[artfwo]

Ah, no, dput and dget are only required for package development, they also can be installed with --no-install-recommends apt argument to reduce the number of installed dependencies.

dget is just a convenience utility to download the .dsc, .debian.tar.gz and .orig.tar.gz files from the source repository (PPA in this case). It will also unpack the .orig source tarball and copy debian packaging fules from the .debian tarball into the package folder, so it's ready to go with dpkg-buildpackage or debuild.

You can also manually get those files from the "package details" page here (expand any version in the package list to see the list of files):

https://launchpad.net/~artfwo/+archive/ubuntu/monome/+packages

For an example of a patched package, see the .debian tarball for one of the earlier serialosc packages, e.g. this one:

https://launchpad.net/~artfwo/+archive/ubuntu/monome/+sourcepub/3597753/+listing-archive-extra

I think in simple cases it's safe to use Ubuntu packages on Debian, as the base system for both distros is not very different (Ubuntu Jammy is based on bookworm). Also, serialosc has no Ubuntu-specific dependencies.

If you have own build and hosting infrastructure, a fork is probably the best option, maybe something similar to what Debian has in debian-multimedia.

[x37v]

Ahh okay, I see.. I was able to download the 2 binaries and install them via dpkg just fine on my 32-bit bookworm armhf system.

wget https://launchpad.net/~artfwo/+archive/ubuntu/monome/+files/libmonome1_1.4.6-0ubuntu2~jammy1_armhf.deb
wget https://launchpad.net/~artfwo/+archive/ubuntu/monome/+files/serialosc_1.4.3+git20230330-0ubuntu2~jammy1_armhf.deb
sudo dpkg -i libmonome1_1.4.6-0ubuntu2~jammy1_armhf.deb
sudo dpkg -i serialosc_1.4.3+git20230330-0ubuntu2~jammy1_armhf.deb

I don't love that the service is being run as root, my fork uses DynamicUser.. maybe interesting for you for future packaging: https://github.com/x37v/serialosc/blob/deb/config/systemd.service.usr

[artfwo]

Ah, good point, thanks. I'll update the user option for the next build.

[tehn]

@artfwo would it be a minor change to alter the run user and trigger a build?

i'm still unfamiliar with the packaging process.

[artfwo]

yes, it's fairly minor, i can do a PPA rebuild with DynamicUser option. for DynamicUser we'll need to change port configuration directory from /var/run to /var/tmp (DynamicUser doesn't have write access for most of the filesystem), but the latter should not be erased between reboots, so it's probably ok to use it.

[x37v]

https://github.com/x37v/serialosc/blob/1fc405794103f0a1406717f4b742457cbea667e1/config/systemd.service.usr#L8-L16

IIRC in my testing, using

  StateDirectory=serialosc
  ExecStart=/usr/bin/serialoscd -c $STATE_DIRECTORY

I got a persistent directory /var/lib/serialosc setup, owned by the dynamic user. I guess one potential conflict is that you may already have a directory there owned by root.

[artfwo]

I'm having some issues updating libmonome packaging to a more recent debhelper version, but i think i can upload an update later this week.

[artfwo]

Hey Brian, Alex!

serialosc is now building for both Ubuntu 24.04 and 22.04 here:

https://launchpad.net/~artfwo/+archive/ubuntu/monome/+packages?field.name_filter=&field.status_filter=published&field.series_filter=noble

https://launchpad.net/~artfwo/+archive/ubuntu/monome/+packages?field.name_filter=&field.status_filter=published&field.series_filter=jammy

Both should work for any recent Debian versions (Ubuntu 24.04 is based on Trixie/Sid and Ubuntu 22.04 is based on Bookworm respectively).

I've also updated both libmonome and serialosc to latest upstream versions and serialosc systemd service now uses DynamicUser option too.

One change to Alex's systemd service config from this PR is SupplementaryGroups=dialout option instead of Group=dialout to distinguish COM port access group from the serialoscd process primary group.

Hope this helps!

[tehn]

thank you artem! i really appreciate your efforts keeping things up to date.