devendor rtaudio

[dvzrv]

Rtaudio is a package, that is available on most Linux distributions by default.

Currently it's not (easily) possible to build against a system installed version of rtaudio. All submodule depedendencies are not included in release tarballs on github: https://github.com/monocasual/giada/releases

It would be great to get a configure option to build against a system installed rtaudio (or handle this through auto-detection).

As a sidenote, I'd like to point out, that giada is in Arch Linux' official repositories and not in the AUR anymore. :)

The problem here is that Giada needs a custom version of RtAudio to enable JACK transport capabilities on Linux (and macOS). I've recently opened a pull request to discuss whether our changes could be somehow merged in the official RtAudio code base.

Currently RtAudio is included as a git submodule that points to our custom version. Is this bad for packagers?

As a sidenote, I'd like to point out, that giada is in Arch Linux' official repositories and not in the AUR anymore. :)

Sounds great!

[dvzrv]

Currently RtAudio is included as a git submodule that points to our custom version. Is this bad for packagers?

If the version is not included in a tarball, yes, as in this case packagers have to rely on (in giada's case) unverifiable - as in: not signed - tags/commits of the repository directly to get to the code, which might or might not work for some distros/downstreams.

In general it's of course also advisable to use rtaudio verbatim for releases and modified versions at best in test releases (e.g. alpha). The current release (0.16.2) doesn't allow using a system version of rtaudio (even if the upstream packages the correct version) due to the modification (and prevents me from packaging this version currently).

@dvzrv please forgive my extreme ignorance when it comes to packaging stuff for Linux distros - I'm willing to learn new things :) So, if I understand correctly, an external library is verifiable (i.e. signed) only if it comes from the distro repository or is included in a signed tarball. Right?

Since we cannot use - so far - the system version of rtaudio, the only option is to hardcode it into the tarball.

[dvzrv]

No worries. There's always plenty of things developers can not be aware of. ;-)

So, if I understand correctly, an external library is verifiable (i.e. signed) only if it comes from the distro repository or is included in a signed tarball. Right?

No and yes, the verification can be established by upstream (i.e. you) by e.g. adding a detached PGP signature for a specific artifact/ asset (e.g. source tarball, prebuilt binary tarball), uploading the public key in use to the keyservers and notifying any users about the keypair in use (e.g. README or elsewhere).
Another way to go about it is to sign commits and/or tags with the aforementioned PGP keypair. This way downstreams are able to check out a specific version/commit and verify it (and its submodules).

The latter is particularly useful in the case where git submodules are being used, as they are not included in snapshot tarballs (the ones, that are automatically created upon tagging a repository on github).
When tarballs are being created by the author (i.e. with the submodules at the given commit included) the first variant is enough, as trust is derived from the upstream creating the tarball and signing it. In said case even the plain tarball with all required sources (without a detached signature) would be at least something downstreams can check (by comparing a checksum of a tarball).

As currently neither is possible, I can not simply check out e.g. 0.16.2 and include the submodules, as this would degrade the current security guards: Tarball retrieval (i.e. downloading a tarball that can be compared against a checksum) with TOFU.

btw: A possible way around the tarball issues when using git submodules is to rely upon git-subtree!

Since we cannot use - so far - the system version of rtaudio, the only option is to hardcode it into the tarball.

Yes, currently the only way to release a proper tarball would be to create one e.g. by script which includes all the submodules and then upload it as a separate asset (which has been done for 0.16.0).
Additionally it is of course always awesome, if upstreams start using PGP signatures for (annotated!) tags and /or even for commits (when only lightweight tags are in use) and the released artifacts.

@dvzrv , first of all thank you very much for the detailed explanation! I'm about to push a new version 0.16.2.1 with the fix.

Now, let's pretend the RtAudio issue is solved (that is, our changes are included in the official repo). What if:

• all external dependencies are git submodules;
• a regular user that just wants to build Giada would simply check out the git repo, initialize submodules and build;
• a packager would pass a new --enable-system-dependencies flag to the configure script to instruct it to link against system libraries instead of the git submodules.

We already have something like this for Catch (the unit-test library) as you may see here. Could this be a viable solution?

[dvzrv]

Yes, ideally the dependencies are detected by the build system and action is being taken due to that (either the system version of a dependency is used, or the vendored one if available). This can also be done manually via flags of course.
At any rate, there should be some sort of feedback in output in regards to this.

The external dependencies as git submodules only work (from a packaging perspective), if they will be included in a source release tarball (as is done for 16.1) , or if the git tags/commits are verifiable (i.e. PGP) themselves.

As a sidenote: The catch flag doesn't work (for me), because I still have to modify the includes of the tests afterwards (the headers are namespaced):

# fixing catch2 include for system library
sed -e 's|catch\.hpp|catch2/catch\.hpp|g' -i tests/*.cpp

[dvzrv]

@monocasual has there been any progress on getting a source tarball for 0.16.2.2, that includes the sources of your modified rtaudio and the nlohmann-json submodule?

[dvzrv]

If you're interested I can provide a script to create a source tarball with all submodules included, that can optionally also sign that source tarball with your PGP key.
I've provided a similar script to other projects such as SuperCollider already.

@dvzrv the script would be great, while waiting for the --enable-system-dependencies flag.