sonobus
sonobus copied to clipboard
FYI: Debian Buster Builders
After several tries, built and came up fine on Debian 10. I have yet to connect or play, however. But the GUI shows both ALSA and my Jack install. Dependencies were an issue on the first builds. Here are the package substitutions that I found in the Buster repos to get the build:
- ibcurl4-gnutls-dev
- libfreetype6-dev
Hope this saves other Debians some time. More as I explore.
I made a very rudimentary Debian package; add a file /etc/apt/sources.list.d/sonobus:
deb [trusted=yes] https://storage.sesse.net/sonobus/ ./
Then run apt update and apt install sonobus. There are source packages in the same directory.
I made a fork and pull request for an installation script that also adds a desktop entry and icon. The script can be found here.
If you could include these in the deb that would be great.
It sounds reasonable to have the .desktop file and icon in the .deb, but it should probably come from master. Let me know when the PR is merged?
@sesse do you know the process to get upstream debian to accept packages?
I'm a Debian developer, so I can upload them if needed. (There's a manual check for the first uploaded version of a package, mostly related to license/legal stuff and avoiding really dumb mistakes. It typically takes a few weeks, depending on the complexity of the package.) But SonoBus would probably be an uphill battle due to the vendored libraries, which is generally not accepted by Debian policy, so I would probably advise having the package on the outside, at least for the time being.
All the vendors libraries either have GPL, BSD, or MIT licenses, AFAICT. Thanks for the info!
I know, it's not a license issue. It's that Debian policy (like most other distributions) is to have only one copy of each library in the distribution, maintained as a separate package. First and foremost, this is so that it's easy to fix any security issue that may come up.
This is an increasingly difficult position to take when newer languages (e.g. Go, Rust, Node.js) increasingly rely on static linking and vendoring libraries, and a single project can have a thousand direct and indirect dependencies. But right now, that's where it's at.
Whatever. The ones I include I have made modifications to, either because they are intended to be source libraries (and not linked to, like JUCE), or because they are bleeding edge and I have my own forks.
Sure, I'm not saying you're doing something wrong, just what the general policy is.
Understood, every group has their own eccentricities!
It sounds reasonable to have the .desktop file and icon in the .deb, but it should probably come from master. Let me know when the PR is merged?
Why would you merge a PR if you can just ignore it amirite
It sounds reasonable to have the .desktop file and icon in the .deb, but it should probably come from master. Let me know when the PR is merged?
Why would you merge a PR if you can just ignore it amirite
The PR is merged!
There's no .desktop or icon merged in the repository, what I can see. The install script was merged, but it refers to files that don't exist.
There's no .desktop or icon merged in the repository, what I can see. The install script was merged, but it refers to files that don't exist.
Looks like it didn't make into his PR, I just manually added and pushed it, thanks!
As for the icon, you can pick any of the sonobus icons/logos in images, whichever works best.
I updated the Debian packaging with adding the .desktop file.
FWIW, the package is still not Policy-compliant, even disregarding the vendoring; in particular, debian/copyright (describing what files are under what copyrights and licenses) is just the default template, and a few other things. But it probably doesn't matter as long as it's not going up to the archive.
I updated the Debian packaging with adding the .desktop file.
FWIW, the package is still not Policy-compliant, even disregarding the vendoring; in particular, debian/copyright (describing what files are under what copyrights and licenses) is just the default template, and a few other things. But it probably doesn't matter as long as it's not going up to the archive.
Thanks @sesse! So, what is the best way to let Debian users know about this in the docs and a realistically easy way for them to use your packages?
@sesse I just committed some updates to the scripts to make them more flexible (can install to specified location, install the VST3, etc). I also added a new ubuntu_get_prereqs.sh script to install all the prereq packages in one shot, for Ubuntu. If you guys could make a version for Debian that would be great, I know it will likely be almost the same. Eventually we can make one script to rule them all that will detect distributions, maybe. Thanks!
The build-depends named in debian/control should be sufficient:
sudo apt install libasound-dev libfreetype-dev libcurl-dev libopus-dev libgl-dev libjack-dev libxrandr-dev libxinerama-dev libxcursor-dev
although I guess you need to look through your licensing and see whether it's libcurl4-gnutls-dev or libcurl4-openssl-dev you want.
As for how to get packages, my packaging is just a one-off. Pragmatically, you'd probably want to import the debian/ directory (unpack the .debian.tar.xz) into your git and then build packages in CI.
To build SonoBus from the source code on Debian 10, you also need the g++ package (it may sound obvious but you get a very cryptic error message from the makefile if it is missing).
To simply run SonoBus, the dev packages are obviously not needed.
Huh, that's strange; I built the package in a pbuilder, which installs a minimal set of dependencies, and it built just fine. But yes, you should have a build-dependency on g++ as well.
@sesse Take a look at https://github.com/essej/sonobus/blob/main/Builds/LinuxMakefile/ubuntu_get_prereqs.sh , I use the build-essential target there to grab all the generic compiler deps for ubuntu.. is there a similar one for Debian?
If one of you could just copy that file and substitute in the right package names that work without error on Debian, that would be the easiest... then submit a PR with it. Thanks!
Yup, build-essential exists on both platforms.
I made a very rudimentary Debian package; add a file /etc/apt/sources.list.d/sonobus:
deb [trusted=yes] https://storage.sesse.net/sonobus/ ./
Then run apt update and apt install sonobus. There are source packages in the same directory.
You shoulded put this on readme.
@sesse on a Debian 10 (aka Buster) I get, upon trying to install your debian package:
The following packages have unmet dependencies:
sonobus : Depends: libc6 (>= 2.30) but 2.28-10 is to be installed
Depends: libgcc-s1 (>= 3.0) but it is not installable
On Wed, Jan 27, 2021 at 09:54:18AM -0800, Sandro Santilli wrote:
@sesse on a Debian 10 (aka Buster) I get, upon trying to install your debian package:
The following packages have unmet dependencies: sonobus : Depends: libc6 (>= 2.30) but 2.28-10 is to be installed Depends: libgcc-s1 (>= 3.0) but it is not installable
Yes, they're built on unstable.
/* Steinar */
Homepage: https://www.sesse.net/
So maybe the summary of this ticket should be updated to mention another name ? I'm a bit lost with Stable/Unstable/Testing changing "release names" as time passes...
On Wed, Jan 27, 2021 at 10:04:50AM -0800, Sandro Santilli wrote:
So maybe the summary of this ticket should be updated to mention another name ? I'm a bit lost with Stable/Unstable/Testing changing "release names" as time passes...
Right now stable = buster, testing (soon frozen and eventually becoming stable) bullseye. You always have unstable = sid.
So yes, my builds were probably somewhat offtopic to the thread.
/* Steinar */
Homepage: https://www.sesse.net/