Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 10 of 17

Hybrid View

  1. #1
    Senior Member
    Join Date
    Jul 2008
    Posts
    119

    LMS on Alpine Linux

    I've got:
    Code:
    Logitech Media Server (v7.9.2, 1576909043, Sat Dec 21 07:49:57 CET 2019) perl 5.030001 - aarch64-linux-thread-multi
    Running on a Raspberry Pi 4 with Alpine Linux 3.11.2:
    Code:
    Linux rpi4 5.4.6-0-rpi4 #1-Alpine SMP PREEMPT Tue Dec 24 11:53:25 UTC 2019 aarch64 Linux
    Besides my bumbling (but ultimately successful) install with Fedora 31 on the Pi 3 B+, I don't have much experience with installing LMS other than from the Windows installer or a Linux package of some sort.

    I've read multiple posts on the subject like:

    This guide by Roland0
    This post by Stuarty
    and this succinct one from Paul-

    Paul-'s post doesn't mention needing slimserver-vendor. I guess I'm a little unclear still about the relationship between Perl versions, module versions, the two repos (slimserver-vendor and slimserver), and the various packages.

    For this effort on Alpine, I mostly followed Stuarty's post above, basically:

    - Cloned the slimserver-vendor repo and built the modules directly on the RPi4 with Alpine. This did require some minor edits here and there to get everything to build correctly. I can post my notes if anyone is interested.
    - I also built the other binaries from the slimserver-vendor source (alac, faad, flac, sox, and wvunpack)
    - Downloaded the "Logitech Media Server: Unix Tarball - No CPAN Libraries" archive and moved the modules under arch/5.30/aarch64-linux-thread-multi/ and binaries under Bin.

    That seems to work ok, I can access the web interface, complete the setup, and stream music to a client. I haven't tested much beyond that.

    I'm interested in feedback on whether this is a "good" process for getting a working LMS on an OS that doesn't have a pre-built package? My next step would be to try to get an APKBUILD together for it but I don't really want to go down that road until I have better feel for whether I'm taking the right build approach here or not. I've looked at some of Gentoo's ebuild files for LMS and they are a little scary (to me).

    Based on Roland0's post, I *think* the main con to my current approach is that I'm tying the modules to the Perl version shipped on this release of Alpine which means that if Alpine updates Perl then that might break LMS?
    Last edited by sodface; 2019-12-29 at 07:12.

  2. #2
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    991
    Quote Originally Posted by sodface View Post
    I was going that direction, building slimserver-vendor modules against the current Alpine Perl version and then combining with the unix-noCPAN tar file to get a working installation.
    There likely isn't an elegant solution to the dependency issues without including a specific version of perl in your package. You can either supply binary modules for multiple perl versions (which is what the LMS deb packages do), but you won't be able to create these with a APKBUILD. Or you can provide the binary modules for only one perl version (i.e. the one on the machine where the APKBUILD is done), which means it will not work on different Alpine versions (or even the same Alpine version if perl gets upgraded - not sure if this happens). I don't know if your package can depend on a specific perl version, but even if, it's won't really help, as Alpine seems to remove old packages from the repo, so users couldn't install them anyway.
    Since I'm not familiar with Alpine, I don't know if including perl in your package is acceptable (on the distros I know, it wouldn't be). If it isn't, and Alpine doesn't upgrade perl major versions within a Alpine version, you'd have to provide a different LMS package for each Alpine version. If it does, you're out of luck.

    The old module sources sort of bothered me and then I read this post by you: https://forums.slimdevices.com/showt...ndled-with-LMS
    First, note that there are non-binary modules in lms/CPAN as well (e.g. Algorithm::C3), which are included in the non-CPAN tarballs. I've never bothered to update those.
    fwiw, the last build I did uses the following versions and has run without any obvious issues for ~3 months:
    Code:
    Audio-Cuefile-Parser-0.02.tar.gz	Module-Build-0.4224.tar.gz
    Audio-Scan-1.01.tar.gz			Mozilla-CA-20180117.tar.gz
    Canary-Stability-2012.tar.gz		Net-SSLeay-1.85.tar.gz
    Class-C3-XS-0.14.tar.gz			Sub-Name-0.21.tar.gz
    Class-XSAccessor-1.19.tar.gz		Sub-Uplevel-0.2600.tar.gz
    DBD-SQLite-1.64.tar.gz			Template-Toolkit-2.26.tar.gz
    DBI-1.641.tar.gz			Test-NoWarnings-1.04.tar.gz
    Data-Dump-1.23.tar.gz			Test-Warn-0.32.tar.gz
    Digest-SHA1-2.13.tar.gz			Tree-DAG_Node-1.29.tar.gz
    EV-4.22.tar.gz				Types-Serialiser-1.0.tar.gz
    Encode-Detect-1.01.tar.gz		XML-Parser-2.44.tar.gz
    ExtUtils-CBuilder-0.280224.tar.gz	YAML-LibYAML-0.63.tar.gz
    HTML-Parser-3.72.tar.gz			common-sense-3.74.tar.gz
    HTML-Tagset-3.20.tar.gz			db-5.3.28.tar.xz
    IO-AIO-4.34.tar.gz			expat-2.2.6.tar.bz2
    IO-Interface-1.09.tar.gz		ffmpeg-0.8.4.tar.bz2
    IO-Socket-SSL-2.059.tar.gz		giflib-4.2.3.tar.gz
    Image-Scale-0.14.tar.gz			libexif-0.6.21.tar.bz2
    JSON-XS-3.03.tar.gz			libjpeg-turbo-1.5.3.tar.gz
    Linux-Inotify2-1.22.tar.gz		libmediascan-0.1.tar.gz
    MP3-Cut-Gapless-0.03.tar.gz		libpng-1.6.37.tar.xz

    Which got me second guessing the approach I was taking. I'm thinking about taking a mixed approach and taking the current Alpine Perl packages (many of the modules are in the repos too) building anything that's missing and then bundling everything together as a separate package with the Perl stuff self contained with LMS.
    I don't see any point in this approach - you will need to build the binary modules specifically for LMS anyway and cannot re-use the ones installed. The only advantage is that you could re-use the already downloaded sources in the local cache (provided you have run the official APKBUILDs and do not just use the binary package), but then you would build the modules twice without needing to (and have them installed twice as well). Much easier to list the module sources in the sources for the APKBUILD, then the akp tool will download them for you and you can use the version from the local cache in your build script (I guess - at least, with gentoo's portage, that would work)

    That way the Perl and modules match the Alpine versions as of today but they are self contained and would remain static as Alpine does updates. I could then update the package at a later date if I felt the need.
    There really is no advantage in the LMS CPAN modules matching the Alpine versions unless you plan to actually use the Alpine versions for LMS (which I really do not recommend - the Gentoo ebuild tried that, and it was a disaster -there's a reason it's now a binary package with it's own modules)

    I've looked at some of Gentoo's ebuild files for LMS and they are a little scary (to me).
    The Gentoo ebuilds I'm aware of are either ancient and broken
    or binary packages, which means the ebuild does not include actually building it.

    Some random thoughts:
    Make sure your versions of faad, sox etc. don't conflict with the ones provided by Alpine
    Include your own Slim/Utils/OS/Custom.pm (example) to set pathnames.
    If you need OpenRC scripts, this one for Gentoo should get you started.
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  3. #3
    Senior Member
    Join Date
    Jul 2008
    Posts
    119
    Thanks for the reply Roland0. I'll review this information and hopefully come up with something that makes sense. One follow on question for you, when you say "the last build I did" and then provide the list of source tarballs, do you mean that you used the slimserver-vendor buildme.sh script with those updated sources or did you build them some other way that didn't rely on any lms related scripts?

    Or asked another way, is there some difference between building a module against the OS installed perl version using the LMS buildme.sh script and just using the same module if it's available in the repos?

    See here for example:
    https://pkgs.alpinelinux.org/package...erl-dbd-sqlite

    I'm fairly confident I can at least get a working LMS for myself to use, I'd prefer it be built with newer perl and module versions (just because). I can probably also manually assemble a package for it just to make it easier to install and share. Making an APKBUILD so that the build system can build the package is probably not worth the effort if I could even get it working. Seems a self contained LMS package with its' own perl and modules bundled with it and installed outside of the normal system perl path might be the right way to go.

  4. #4
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    991
    Quote Originally Posted by sodface View Post
    One follow on question for you, when you say "the last build I did" and then provide the list of source tarballs, do you mean that you used the slimserver-vendor buildme.sh script with those updated sources or did you build them some other way that didn't rely on any lms related scripts?
    slimserver-vendor buildme.sh (patched for new versions)

    Or asked another way, is there some difference between building a module against the OS installed perl version using the LMS buildme.sh script and just using the same module if it's available in the repos?
    Yes there is. Take e.g. Image::Scale, which depends on libjpeg-turbo (and other pkgs). The buildme script will build a static version of libjpeg-turbo and then Image::Scale, which will link against this static library (and libjpeg-turbo never gets installed). A system package of Image::Scale will depend on libjpeg-turbo being installed, and Image::Scale will link against the shared library of libjpeg-turbo in /usr/lib.

    I'm fairly confident I can at least get a working LMS for myself to use, I'd prefer it be built with newer perl and module versions (just because).
    There are definitely performance/stability/security improvements with certain upgrades (perl, SQLite, libjpeg, libpng). While we'are at this topic: Check if your CFLAGS include the optimizations for your platform (or at least -O2 -march=native (which may be suboptimal depending on your gcc version's support for your plarform))
    For pi3 / aarch64 I use -march=armv8-a+crc -mtune=cortex-a53 -O2

    I can probably also manually assemble a package for it just to make it easier to install and share. Making an APKBUILD so that the build system can build the package is probably not worth the effort if I could even get it working. Seems a self contained LMS package with its' own perl and modules bundled with it and installed outside of the normal system perl path might be the right way to go.
    Writing the APKBUILD to automate the steps to build/install LMS (d/l sources + support files (init scripts etc.), run buildme.sh, create user, install files etc) wouldn't be that much of an effort if you are exploring how to get it to build/run anyway (it's just a shell script after all). That way, you (or any user, really) could run the apk build locally for your perl/arch (provided they have installed the build env). This would make installing / upgrading / removing) rather simple. You could then make the APKBUILD file available for d/l if there's demand, but not the resulting binary package.
    That being said, I couldn't be bothered to do this for Gentoo myself, so there's that...
    Various SW: Web Interface | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  5. #5
    Senior Member
    Join Date
    Jul 2008
    Posts
    119
    You guys are probably getting tired of these Alpine Linux threads but, I've been working on an armel port (see this thread) and I've got everything built for LMS I believe and now I just need to package it up. I sort of left this thread and Roland0 hanging a couple of months ago and now it's time to revisit it.

    If anyone has any input on how best to package up LMS I'd love to hear it. With this armel port, I think it's pretty safe to just make perl a separate package as there's nobody upstream to update it. So I'm thinking maybe:

    - Perl 5.30 as a separate package (already built and in the repo)
    - LMS modules as a separate package (not sure this makes any sense)
    - LMS openrc scripts as a separate package
    - LMS no CPAN itself as a package

    I guess I'm thinking that with the first three installed, updating just the LMS package could be done more frequently?

    I'm also wondering about file system paths, I've looked at my Fedora install and I feel like things are scattered around a little, probably for good reason, but if anyone has any suggestions on where things should land that would be good too. Thanks.

  6. #6
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,474
    I run LMS from git in /opt/logitechmediaserver and everything stays contained within that folder other than searching for system utilities as long as you set the folder locations when you start it.

    Code:
    /opt/logitechmediaserver/slimserver.pl --prefsdir /opt/logitechmediaserver/prefs --logdir /opt/logitechmediaserver/Logs --cachedir /opt/logitechmediaserver/cache --charset=utf8
    From the server information tab.

    Code:
    Cache Folder
    /opt/logitechmediaserver/cache
    
    Preferences Folder
    /opt/logitechmediaserver/prefs
    
    Plugin Folders
    /opt/logitechmediaserver/cache/InstalledPlugins/Plugins, /opt/logitechmediaserver/Plugins
    
    Helper Applications Folder
    /opt/logitechmediaserver/Bin/i386-linux, /opt/logitechmediaserver/Bin, /usr/local/sbin, /usr/local/bin, /sbin, /bin, /usr/sbin, /usr/bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/CastBridge/Bin, /opt/logitechmediaserver/Plugins/DSDPlayer/Bin/i386-linux, /opt/logitechmediaserver/Plugins/DSDPlayer/Bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/PlayHLS/Bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/ShairTunes2W/Bin, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/Spotty/Bin/i386-linux, /opt/logitechmediaserver/cache/InstalledPlugins/Plugins/Spotty/Bin, /opt/logitechmediaserver/Plugins/Xplay/Bin
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 1-UE Radio
    Squeezebox client builds donations always appreciated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •