On Tue, March 28, 2017 2:52 pm, list wrote: I also find the same problem on Fedora 25. These were the only packages I could find in the Fedora repositories with "capnp" in the package name: capnproto-devel-0.5.3-2.fc25.x86_64 capnproto-0.5.3-2.fc25.x86_64 capnproto-libs-0.5.3-2.fc25.x86_64 Installed all, still fails configure. There is no mention of the phrase "capnp" in either INSTALL.txt or README. -- Chris Caudle

Am 29.03.2017 um 08:56 schrieb Chris Cannam: That's a stupid thing to do for a stable relase of an application, IMHO. How does the SV project expect distribution package maintainers to package the application if it depends on unreleased versions of other software? Chris

Hello. Sad to read that. Will use the Gnu/Debian jessie 2.4.1 package, waiting for stretch to be stable to have the 2.5 version. I do not like to mess around with «stable». Anyhow, nice software, really fun to work with. Learn a lot of things thanks to it. Keep up the good work ! All the best. Le Sat, 1 Apr 2017 14:06:59 -0400, Bernardo Barros <bernardo.barros(a)nyu.edu> a écrit :

Am 01.04.2017 um 20:06 schrieb Bernardo Barros: I would prefer SV to be programmed in a way that it doesn't need a git "version" of capnproto. I think, distribution do not package unspecified git repo states as packages in their stable package repositories* for a reason. I think that's a good thing and not a limitation. Chris * on Arch you can install AUR *-git packages, but if you do that, it's with the knowledge that this is totally unsupported.

Am 02.04.2017 um 05:39 schrieb Bernardo Barros: Thanks for explaining your world view. I'm a developer myself. Now what? If SV depends on unreleased code, maybe it would be a good idea to include it in the release tarball? Yeah, established practices in packaging (like making sure your dependencies are installable) are meaningless. Am I bothering you? I'm so sorry. Chris Chris

On Sat, 1 Apr 2017 14:49:41 -1000, david wrote: That's a good one! Try to build something as a snap that needs access of something outside of the snap ecosystem, e.g. if jackd should be needed. Good luck! I've tested it ;). IIRC you could use some "insecure" developer mode, to get access to everything outside the "container", but snappy and all the other alternatives are unlikely something that improves Linux real-time audio. Regards, Ralf

On 4/2/17 1:34 PM, Ralf Mardorf wrote: What if that's the only way? "Program in a way that it doesn't the git version"(?) It don't think it's a wise suggestion either without looking for the reasons they did it.

On Sun, 2 Apr 2017 13:42:04 -0400, Bernardo Barros wrote: I understand your argument :), maybe you shouldn't share dependencies, you could make it part of your software. FWIW, apart from snappy and co, there's stille the option to use /opt/ and to include all required dependencies. On Sat, 1 Apr 2017 14:49:41 -1000, david wrote: Btw. building automatically from git at least was a PITA, it might be that they fixed it, since several subscribers lamented :D. I'm to lazy to search the archive, on the quick I only found this: https://lists.ubuntu.com/archives/snapcraft/2016-July/000399.html -- "Michael" described Floyd as "an idiot savant", and added, "Give him any two numbers, and he can multiply them in his head, just like that." Homer, testing Floyd, said, "Five times nine", and Floyd instantly responded "Forty-five", which impressed Homer.

On 4/2/17 1:58 PM, Ralf Mardorf wrote: What happened to `universal snaps`? It's not a bad idea.

A few different things came up in this thread, not all of which are very on-topic for LAU. I'll reply to the batch in one go, but if you want to talk further about developer/packager specifics, perhaps take it off-list or to LAD. Q. How would I (an end-user) build this SV release? A. You'll need a git master checkout of capnproto. The exact revision doesn't matter much, as the master is stable enough that the capnproto developers have been using it in production for some time. If you want a specific revision id, try 86ce27924cea which is the version used in the existing Linux build for SV 3.0.2. It's not that much different from handling any other library dependency your distro happens not to have yet. Yes it's a bit of a pain, yes I somehow forgot to document it, and I am sorry about that. (Of course SV also has a lot of other library dependencies; it's never been all that simple to build. And version 3 needs a fairly modern C++ compiler, so there may be problems with old distributions anyway.) Q. How does the SV project expect distribution package maintainers to package the application? A. Strange question this one. The SV project doesn't expect anything of anyone. I make (currently) four different platform builds of every release to try to get the application to as many potential users as possible, and if it's also available through distro packages then that's a bonus too. If there's a problem packaging it, and a maintainer asks about something that needs fixing, then I'd love to help. If it involves a solution more practical than, effectively, "write a different application" then all the better. I do recall that maintainers have also had problems in the past with applications doing as Ardour does and bundling specific revisions of upstream libraries in the release tarball. Q. Can't an application be packaged with a static-compiled copy of the required library? A. That would seem like a good solution to me -- it's what I do for the existing binary packages of SV -- but I'm not a package maintainer. There may be rules against it. Q. Isn't it really bad practice to depend on an unreleased version in the first place? A. Yes and no. In this case the upstream repo is pretty stable. I'm no more concerned about a capnp update breaking the build than I am about a new release of any other dependent library doing the same. When you run a configure script, you're getting only the most superficial reassurance that the library you're building against is the one the developer expected. It would be nice to pin these things properly, but as it stands the release tarball is closer to being "the code that happened to be in the SV repo when the release builds were made" than it is to a reproducible recipe for making such a build. The present situation just surfaces the reality of that. What I should absolutely have done is identify a specific revision (i.e. 86ce27924cea) as having been tested. Q. Why have this dependency in the first place? A. This software was useful and appropriate, it makes SV a better application, and the APIs that SV uses have been present in its stable recommended interface for over a year. I would like to see (and have asked for) an upstream release, but I don't have any control over those schedules. Q. Could you have provided a multi-distro installer via e.g. Snap? A. I did look into this, without much success -- I'd love to hear of any better experiences from other developers. Canonical's Snap is only ever likely to be supported on Ubuntu, and I already provide an Ubuntu package anyway. Flatpak from Red Hat looks more promising technology, but it also has limited support (presumably as long as Snap exists, Flatpak will never be properly supported on Ubuntu) and it only works on the very newest distro releases. AppImage is conceptually simpler but it certainly didn't seem simple to make a true cross-distro package, and the AppImage example package I tried wouldn't run on my own (Arch Linux) system. Chris

Just to follow up on this thread about Sonic Visualiser's dependency on an unreleased version of capnproto: version 0.6 of capnproto came out today, and should work fine with SV. Chris