On Fri, 7 Oct 2016 15:49:07 +0200 Tito Latini <tito.01beta(a)gmail.com> wrote: Thanks ! That helped getting it built. More specifically I think, since sdl-config was not on the system and since it is part of libsdl-dev, the installation of libsdl-dev made libav build avplay. In this case sdl is version 1.2.15. Cheers.

On 7 October 2016 at 17:16, jonetsu <jonetsu(a)teksavvy.com> wrote: these are two separate packages, so I'm guessing you need to install that as well. Arve

On Fri, 7 Oct 2016 12:21:38 -0400 jonetsu <jonetsu(a)teksavvy.com> wrote: Builds very easily. A simple ./configure; make; make install Thereafter ffmpeg built also nicely, including ffplay. Thanks for the help !

On Fri, 7 Oct 2016 19:03:15 +0200 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: Yes, but that will not help a bit .... wig. A bit of background. What is behind this is the problem that Bitwig cannot read some AIFF files inasmuch as it will play them silently and will not show any waveform for them. Whereas the same AIFF test file will play OK in Ardour, Renoise and with vlc. Exchanging with Bitwig support, the same AIFF file will play fine on teir systems (Linux, Mac, Windows), so there might be a problem with libav/ffmpeg. Ardour is using linsndfile (confirmed by Robin). I do not know for Renoise and vlc, not easy to track with ldd. Using then the original avplay from Linux Mint 17 on that file, and comparing with another AIFF file that plays good, it turned out that avplay cannot play that file. So I built both libav and ffmepg from source since the Linux Mint 17 system is a tad old and I certainly do not want to upgrade the OS, at least for now. Both players then can read the test file. So it looks good so far, but they're installed in the default /usr/local/ location. And this is where the checkinstall, which I did not know about, utility might be very handy, if it does what it says it can do. So your commentary is very good timing ! Sehr toll. Is there any other detail to be aware of, apart from the example you provided, regarding running checkinstall and, most importantly, using the generated package to replace the existing installed components ?

On Fri, 2016-10-07 at 19:54 +0200, Ralf Mardorf wrote:                                                             ^^^^                                                  this should read "file" Oops, this could become an issue ;). You might need to replace them with empty dummy packages using equivs. https://www.debian.org/doc/manuals/apt-howto/ch-helpers.de.html At some point it might be less work to use the Debian/Ubuntu source package with existing rules and control files and just to replace the source by another version of source code. However, using equivs to generate a few dummy packages is less work and there's no learning curve, it's easy to use. If you often do things like this, consider to use a distro with an easier to use package management and a sane package policy. Arch Linux usually doesn't split packages and building a package is very easy to do. Regards, Ralf

On Fri, 07 Oct 2016 20:18:17 +0200 Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote: Well then, there was also "abtitude" then ;) Looks more like I'll be going with a configure system prefix. Yes, Arch would be the one. I think I'd get a bit of building and using Beyond Linux From Scratch while having a ready-to-go packaging system and repo.

On Fri, 2016-10-07 at 14:23 -0400, jonetsu wrote: Keeping the tons of packages and just overwriting could work, too. Assuming two versions of libs are provided, this shouldn't cause an issue. Anyway, as soon as something compiled by yourself gets upgarded by repositories, or a dependency of something you compiled, you could run into trouble. Fortunately Ubuntu stays with major versions of libs, usually only dot versions should change, so you shouldn't expect soname issues, but OTOH you're using Mint and not Ubuntu. You could hold/lock packages. Note, a package locked by Synaptic might not be hold by apt. Regards, Ralf