If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I decided I wanted to rename the lms packages slightly to make them less version specific except for the lms-nocpan package. Probably a bad idea as I borked up my own server install and ended up having to walk through the setup again like it was an initial install. Oops.
Here's the new package names with most of them just being "8" and lms-nocpan being more specific:
aarch64 I didn't "fix" yet to a more generic version 8 and it's a lot behind because I also apparently missed the 8.1 to 8.2 version switch in the script I have cron'd to pull updates and besides that, the builder is an RPi4 which is currently reloaded with armv7 building a kernel for another project I'm working on so aarch64 updates to the below packages might not happen for a bit:
I'm interrestend in your repo. I would like to try installing LMS in an Alpine LXC container (currently using Debian in LXC). If your repository is still working, I would try to do a test install. The architecture is x86_64 of course.
I'm interrestend in your repo. I would like to try installing LMS in an Alpine LXC container (currently using Debian in LXC). If your repository is still working, I would try to do a test install. The architecture is x86_64 of course.
Sorry I missed your post. Yes, the repo should still be working. See Post #1, basically download my public key and add to /etc/apk/keys/ and then add http://www.sodface.com/repo to /etc/apk/repositories. Then sudo apk add lms.
Alpine 3.14 just came out on 6/15 and I hadn't upgraded my server yet, which I did this morning - lms seems to still be working after a reboot so that's good!
I made an attempt to cleanup my repo and update the lms packages to make sure they work on the latest 3.14 release of alpine. Currently lms* in the armhf and armel repos are incomplete/broken and I'm not sure when or if I'll fix them. The following three arch's should be ok to use:
Updated repos and weekly update script to LMS 8.3 branch. I missed that 8.3 was available. I have it installed on my Alpine LMS server:
Logitech Media Server Version: 8.3.0 - 1628023423 @ Tue Aug 3 23:02:57 CEST 2021
Everything seems to be working fine so far.
I did a second container for this, using the latest Alpine LXC image, and the packages in your repository. Unfortunately squeezelite and lms services crash at startup, with default settings. I have tried it with enabling the Alpine testing repo and also without it.
Where can I check the logs for both of these services, as in /var/log/messages there is nothing related to it.
Alpine 3.15.0 was released back on November 24th. Perl was upgraded to 5.34. I just rebuilt the modules for x86_64 and armv7 and updated the repo. I don't have my aarch64 builder set back up yet after the move. I'll get it back online this weekend and rebuild the modules for that architecture too.
[21-12-09 22:42:59.4316] main::init (390) Starting Logitech Media Server (v8.3.0, 1638573231, Sat 04 Dec 2021 12:36:15 AM CET) perl 5.034000 - x86_64-linux-thread-multi
I’m very happy to run squeezelite and jivelite on my Thin client (t620).
I appreciate your effort. I want to run it on my HP t420. HP t420 is 32bit arch. Do you have any plan for supporting x86 ?
Hi blackbird, I'm thrilled to see someone else running Alpine on a thin client and that you were able to use at least my x86_64 packages for squeezelite and jivelite successfully! I do not personally have a need to support x86 and I don't really want to set up another build machine. I've already sort of failed after my recent move to set back up aarch64 and armhf. I'm looking at my pi4 right now, unplugged, dark, and covered in dust
I've done some cross compiling previously for armel so maybe I'll look into that for x86 though probably qemu on my x86_64 builder would be a better option??
See this link for APKBUILD files for jivelite and the couple extra sdl packages not in the Alpine repos:
What's the advantage of using Alpine over say Ubuntu, Not yet got round to playing around with it but I picked up a Wyse 3040 16Gb thin client after your recommendation.
Not sure what it's end use will be yet, but definitely will try it for LMS, thinking also maybe an entire standalone Squeezebox system for taking away on holiday breaks and other option is my OpenVPN server needs a rebuild and I could use this instead of the current Raspberry Pi.
I haven't used Ubuntu much so I can't really make an informed comparison between it and Alpine. It's extremely petty of me, but the cutesy little animal names they use for the Ubuntu releases irritate me and make me not want to use it just for that. I'd rather just say that Alpine kind of just "clicked" for me when I started using it and the fact that they support a bunch of architectures means I can use it everywhere I need it, router, desktop, rpi's, thin clients etc. So far, the only thing that has a been a negative to me is that the Linux version of the proprietary DAW, Reaper, only supports glibc and Alpine is based on musl libc. I've tried to get Reaper to work on Alpine with the gcompat package (a glibc / muslc translation layer) but it isn't stable. I have a license for Reaper and I like it but if I want to use it on Linux I'll have to use something other than Alpine. So depending on your use cases, software compatibility on Alpine may be more of a problem than on Ubuntu. For me, Reaper is the only example that I can give.
I thought this blog post by Drew Devault was good and lines up with my thoughts about Alpine, give it a read:
I haven't used Ubuntu much so I can't really make an informed comparison between it and Alpine. It's extremely petty of me, but the cutesy little animal names they use for the Ubuntu releases irritate me and make me not want to use it just for that. I'd rather just say that Alpine kind of just "clicked" for me when I started using it and the fact that they support a bunch of architectures means I can use it everywhere I need it, router, desktop, rpi's, thin clients etc. So far, the only thing that has a been a negative to me is that the Linux version of the proprietary DAW, Reaper, only supports glibc and Alpine is based on musl libc. I've tried to get Reaper to work on Alpine with the gcompat package (a glibc / muslc translation layer) but it isn't stable. I have a license for Reaper and I like it but if I want to use it on Linux I'll have to use something other than Alpine. So depending on your use cases, software compatibility on Alpine may be more of a problem than on Ubuntu. For me, Reaper is the only example that I can give.
I thought this blog post by Drew Devault was good and lines up with my thoughts about Alpine, give it a read:
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We may share certain information about our users with our advertising and analytics partners. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment