Just a note that the ARCH check in the Makefile should be for "aarch64" not "arm64".

(In reply to Marcel from comment #1)

According to the porters handbook ARCH is the value returned by `uname -m`:

https://docs.freebsd.org/en/books/porters-handbook/porting-dads/#dads-arch

On my ROCK64 machine I get:

$ uname -m
arm64

So, I assume arm64 is correct? I forgot to test arm64. I'll do a testport run now to make sure it works.

(In reply to Trenton Schulz from comment #2)

Interesting! I found this by trying to build the patch on a honeycomb:  packaging fails because %%ARCHNAME%% is blank when it gets to pkg—plist (as expected if ARCH doesn't match anything). Changing to 'aarch64' does the trick. Maybe the handbook needs an adjustment?

I also see:
$ uname -m
arm64

For whatever it's worth, grepping around the ports tree, 'aarch64' is much more common (only lang/racket and related has 'arm64'):

$ grep -r '${ARCH} == "arm64"' /usr/ports/* | wc
2
$ grep -r '${ARCH} == "aarch64"' /usr/ports/* | wc
40

(In reply to Marcel from comment #3)

Well, I have now checked the actual Makefile (bsd.port.subdir.mk) and it appears that ARCH is defined by `uname -p` instead of `uname -m`. So, yes, the check in the Makefile should be aarch64. Perl still generates the arm64-freebsd-thread-multi, though.

Anyway, I'll try and run this one more time through on my local poudriere and update the patch. Happy to know if it actually worked on a FreeBSD arm64 machine after your patch. The older port was i386/amd64 only.

Created attachment 256454 [details]
Updated patch so that arm64 builds

Use correct check in Makefile for ARCH such that aarch64/arm64 is built correctly.

(In reply to Trenton Schulz from comment #4)

Seems to be building+running great on the Honeycomb after that adjustment — been using it daily for nearly a week now and no other issues here!

Created attachment 256641 [details]
Update patch to 9.0.1

Update patch to 9.0.1.

(In reply to Marcel from comment #6)

That's great to hear! Nice to have this also finally working on arm64 too!

The actual name of the new project is Lyrion Music Server, not Lyrion Media Server.  It might be worth correcting that before adding the new port.

Created attachment 257086 [details]
Update patch to use the correct name (Lyrion Music Server)

Yes, of course, it's Lyrion Music Server. Updating the patch. Tested locally and all works well. 

Hoping that this can soon be committed.

Comment 11 Daniel Engberg 2025-02-03 20:40:26 UTC

You probably want https://docs.freebsd.org/en/books/porters-handbook/book/#dads-arch-ignore ?

Created attachment 257236 [details]
Update patch to use ONLY_FOR_ARCHS

@diizzy, Yes, that is a good idea. Technically, the port should work for other architectures, but it generates a custom tuple in Perl that needs to go into the PLIST. I can only test i386, amd64 and aarch64. It's better to go with ONLY_FOR_ARCHS and let the brave comment it out and submit patches.

Otherwise, I hope it is ready to go.

Is there anything else that is missing here? The port has been running well for the past couple of months for me. I would really like to get this version in, so we can eventually remove logitechmediaserver.

Created attachment 258787 [details]
Update patch to 9.0.2

Update port for 9.0.2

Comment 15 Daniel Engberg 2025-03-22 07:12:13 UTC

Looks good although I'm not a fan of the bundling of various ancient libs, is it possible to unbundle those?

(In reply to Daniel Engberg from comment #15)
Possibly, but I think that is a larger task, and I'm not sure of its size at the moment. Lyrion (or Logitech or Slim Devices) have always had their own patched version of libraries/Perl Modules (slimserver-vendor). As far as I know, we use the system libaries where we can, but there are specific versions of Perl Modules that are used for compatibility.

Regardless, that is how the audio/logitechmediaserver port has done it (I inherited maintenance of that). At least these modules are confined to the port and not easily accessible by Perl in general. I agree that it is not optimal, but it does work.

I could eventually look at changing the Perl dependencies to other FreeBSD ports, but that looks like a can of worms at the moment. I feel better about having this version in the ports tree vs. audio/logitechmediaserver as this version removes decades old firmware to allow binary packages versus requiring building locally.

I'm open to suggestions to this being a better FreeBSD Ports/Perl-citizen, but I'd like to see this committed first (or trading place with audio/logitechmediaserver as now there have been a couple of patch versions released).

Comment 17 Daniel Engberg 2025-05-03 10:36:20 UTC

I apologize but I have to return this to the pool for someone else to review, I dont feel comfortable with committing a port that uses ancient bundled libraries.

For what it's worth, I did take a stab at unbundling the Perl dependencies. It's at least as complex as I thought. It's doable, but it will take more time than I can devote to it at the moment.

There are a couple of Perl modules that are old (i.e., they haven't had an update in years), but they are specialized (creating gapless play for mp3 files). I'm unsure how big of an attack surface one gets with this specialized module, since the server runs as an unprivileged user. If there are problematic Perl modules, I can focus on unbundling them.

I'm currently wondering if I should just change this patch be an update to audio/logitechmediaserver (i.e., change name and remove the older port). I'm confused why that port is allowed in with the exact same modules, while this one does not.

(In reply to Trenton Schulz from comment #13)
Just to add me to the of people affected by this.
My current version from ports is almost one year old, by now.

Would a simple name change of the current LMS port raise the same issue?
In the LMS port has always been this the issue:
PKGNAME: there is no package for this port: _LICENSE_RESTRICTED = 

Now that the license issue has been lifted, it be great to make all changes available, in my opinion.

I started fresh in a 13.5 Jail and used the patch
…
After ~6:30h it was done, without any issues!
(It be great to have a pkg available)


Lyrion works as expected.

Created attachment 260876 [details]
Updated patch to check that all works with perl 5.40, remove logitechmediaserver

Update patch again after checking with Perl 5.40 (ARCHNAME is changed on aarch64). I have also decided to use this update to delete the logitechmediaserver port as that version requires more work to get going with Perl 5.40 and the Lyrion update has been working well for me for the last 6 months.

Comment 22 Kurt Jaeger 2025-06-21 06:52:25 UTC

I checked and it does not update the depends of the audio/logitechmediaserver-* ports ? would those still build if the depends are corrected ?

(In reply to Kurt Jaeger from comment #22)

I answered on the ports mailing list first, but just for completeness:

It seems like the dynamic playlist plugin can be installed through the plugins in Lyrion proper now (this feature was added in 8.0), which obsoletes the need to build and install plugins yourself. The other ports are assistants to the dynamicplaylist plugin and don't add much on their own. The webpage in the port references a retired website which only lists instructions for buliding against 7.x. The plugin in
Lyrion goes to a github project page instead and requires >= 8.0.

I think the audio/logitechmediaserver-* ports have rotted and probably
should have been removed when we upgraded the port to 8.x. Should I add an additional patch to remove them as well?

Created attachment 261477 [details]
Updated patch that removes the old, unmaintained logitechmediaserver plugins

I took a look, and it seems best to remove these plugins. I'm not sure that they were working with the current version of LMS in the tree. Upstream has a way to install these plugins directly now, and that is the supported way of doing it.

So, the patch now includes:

Add audio/lyrionmusicserver
Remove audio/logitechmediaserver, audio/logitechmediaserver-dynamicplaylist, audio/logitechmediaserver-lazysearch, audio/logitechmediaserver-sqlplaylist, and audio/logitechmediaserver-trackstat

Comment 25 Mark Linimon 2025-07-15 19:58:13 UTC

^Triage: canonicalize assignment.

Thank you for assignment. The current patch works for Perl 5.40, but doesn't build correctly for Perl 5.42. I have a patch that builds by instead using other p5-ports, but that doesn't work correctly when run. I'm chasing that down, but probably won't have time to really solve it until the end of the month.

Comment 27 Daniel Engberg 2025-09-17 19:50:14 UTC

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283493#c17

Comment 28 Poul-Henning Kamp 2025-09-20 15:18:37 UTC

Datapoint:

I downloaded the 261477 patch, it built without any problems on 14.3-RELEASE-p2 amd64, and I'm now listening to Madnesss through it.

Thanks a LOT!

Created attachment 263991 [details]
Updated patch to work with Perl 5.42

Updated patch to work with Perl 5.42. This was mostly achieved by stopping to use vendor version of the Perl modules and instead use ones from the ports tree. I've currently switched to three ports, which is enough to get Perl 5.42 work and remove some old libraries. More can be converted, but it is a slow process to test, and it's better to get this technical debt paid down in increments.

Created attachment 264459 [details]
Update patch to 9.0.3

Updated patch, use a couple more of FreeBSD modules (including p5-DBD-SQLite, which cuts down significantly on build time for this port).

Created attachment 264622 [details]
Update patch to 9.0.3 for real

Grabbed wrong commit SHA in previous patch. This is the correct one.

Comment 32 Poul-Henning Kamp 2025-10-19 22:10:44 UTC

latest patch (2025-10-16 14:23UTC) tested, works.

Again: Thanks!

Is there an ETA on when this might be committed?  I've been using LMS 8.5.2 with perl 5.38 in the meantime, but upgrading to 15.0-RELEASE has caused plist issues during 8.5.2's package building stage, so I'm wondering if I should try to fix the plist of 8.5.2, apply this patch, or wait until it's committed.  Thanks for the work so far!

(In reply to David Zuckerman from comment #33)

I would go for this patch as I (the maintainer) use this daily. It works with Perl 5.43 (and Perl 5.40 if one still has that). The way 8.5.2 is built makes it a headache for changing the plist on Perl update.

This port is also using more dependencies from the ports tree, so builds faster. I have also removed the offending licensing files, so it can be distributed as a package when it is committed.

It would be great to get this committed, I agree. In theory, there are a few more modules that should be using the ports tree, but I haven't had time to look at them. (Nor have I had time to ask politely again for someone to commit). The current version is much better than the 8.5.2 that is in the tree.