Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
> I now know about, (and showed the guy who did the port I'm running) the > slimserver-vendor tree that contains a very complete set of CPAN > libraries (and other stuff) that locks in all the nitty-gritty bits to > keep LMS working. The author of the port I'm running showed me that I misunderstood how he was packaging things up. He is actually pulling in the CPAN libraries from https://github.com/Logitech/slimserver-vendor/CPAN/ So he got it right in that regard, and I didn't understand how he was doing the packaging. LMS 7.9 - 2xSB2, 2xBoom, 2xKodi, Ocean Digital WR2300S, Denon AVR-X6200W, SHIELD Android TV wcattey's Profile: http://forums.slimdevices.com/member.php?userid=7506 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
mherger wrote: > >But whatever we do, I believe we need to understand why a file was > there, why a patch was applied, and make sure we don't break that > condition. Think of other platforms than yours. Because you looking into > > this most likely are looking into this because you're in a very, very > small minority of users running an unsupported platform. In my opinion the main thing to note here is that the buildme script creates both Perl modules and binaries *outside* the awareness of your system's package manager. This is something I failed to realize at first myself and as a result I found myself spending tons of time to keep LMS running as my system progressed through newer versions of Perl. The concept of the buildme script is old, really old, and should not be used on any modern system. In particular if you are on a binary release it makes no sense whatsoever to build something like ffmpeg because it is bound to be inside the system's repository and in fact likely already installed, so you can instantly link to it either statically (like the buildme script does with the historic versions) or dynamically. Using your system's package manager allows for seamless upgrades of both Perl and individual modules and takes care of changed dependencies (like the `new` module Canary::Stability). In effect there is only one real problem and that is that the slimserver-vendor project only aims to build the CPAN modules that have a binary dependency. Any other module including those that are referenced by modules included in the buildme script are part of a fixed tree even though LMS has no dependency on any specific version and that is what causes isues on practically every unsupported platform, because some of the newer modules that are needed for newer Perl do require minimum versions that are higher than the ones in LMS `noCPAN`. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
I think there current strategy for LMS on Windows is to keep using the current system and CPAN library as it requires least effort and is least riskiest but any strategy to update CPAN modules also has to include a strategy on how to provide LMS on Windows in a easily legal distributable way. Thanks bpa. Yes, Windows certainly is one trouble maker. But then we _can_ update certain dependencies for other platforms and just leave some behind, like Windows. As long as we don't break LMS by using new features or adapt to breaking changes, we should be good. We've done this for quite a few modules (Audio::Scan, SQLite). But those breaking changes can be a real challenge, and I believe some of the modules are there for this very reason. I'd have to check the commit history, but I believe Andy at some point hit this kind of a road block with one of the modules. Another challenge some might be missing is SQLite support. There are optional features we include which likely are not part of a default installation's version. Eg. enhanced support for unicode. Many of those who are happily using a system's library might simply not be in need of it. But it's there for a good reason. To get back to the OT's request: I'm sure there's a lot of space for improvements in that CPAN handling. Alas... it's working fine for 99.9% (and some more) of all users. Therefore priority/motivation to work on it is very low. I've always been open to improvements. That one pull request I did not refuse because I didn't like the idea. But I asked its author to break it up into manageable chunks, because it was just overwhelming. I could imagine going on a module by module level: update/remove them individually. This way it would be easier to revert if we encountered issues. We could remove support for all but the latest version of any given module (there are threef for Audio::Scan), as we're likely never going to build an old version again. And it's true that we don't need support in the build process for really old Perl versions. This could be cleaned up, too. But whatever we do, I believe we need to understand why a file was there, why a patch was applied, and make sure we don't break that condition. Think of other platforms than yours. Because you looking into this most likely are looking into this because you're in a very, very small minority of users running an unsupported platform. ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
The maintainers of LMS have to strike a balance betweeen updating modules and retaining the current versions. I think Windows support is one area which may be holding back updates. There are a lot of Windows users and Activatestate has stopped supporting the build system used by LMS. The Perl used by LMS on Windows is stuck on 5.14 - however the support for the libraries etc was also stopped. If there is a new equivalent from Activestate (or other), I'm not sure Logitech will pay for the necessary package & licence to distribute. I think Ralphy has managed to build updates for some modules (e.g. SSL/TLS related) but to update all CPAN modules may take a lot of effort- if possible. In the last 12 months, the push to used "https" by stations has meant a lot of users have had to upgrade their Windows as well as the LMS. This has helped to bring the user base up to date and is now less diverse. I think there current strategy for LMS on Windows is to keep using the current system and CPAN library as it requires least effort and is least riskiest but any strategy to update CPAN modules also has to include a strategy on how to provide LMS on Windows in a easily legal distributable way. bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
Yup! Debian developers are pretty good at what they do. I'm still trying to figure out how they manage to compile OpenJDK for softfloat arm... There is however of course a reason why even Debian does not have an LMS package for every their supported CPUs and as many Synology users may confirm it is not because it is dreadfully slow on arm5. And no I don't know what trickery they pulled but if I had to guess it will be related to process instance isolation to avoid module version hell and as that would cause excess memory usage on tiny systems that's why they are not offering it. On Gentoo I go a different route. I do not pack the arch specific modules but reference the OS supplied packages (I had to add a few myself) for those instead. This takes me out of harms way with respect to Perl but also introduces a new issue because the required packages have dependencies on modules that are inside the LMS noarch (confusingly named noCPAN) tree but because the OS package manager is not aware of them it installs its own versions of those modules and versioning hell is once again imposed on the installation as some of the arch specific modules actually do require a newer version for one of their dependencies than supplied in the LMS tree. Michael hates it, but I fix this in my package configure script by removing all duplicates inside the LMS tree. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
gordonb3 wrote: > That's the whole culprit, isn't it? If you do it every week you're bound > to know all the pitfalls. The reality is that even with an average of > once per year you end up hitting a wall with errors that at first don't > seem to make any sense at all and once you figured it out you find > yourself needing to manually clean up left and right because some other > package on your system pulled in a different version of a module used by > LMS and LoadModule matches the wrong .so to the .pm (which is what the > cryptic error message was about). > > LMS is nice for Windows and dedicated (VM) systems, but if you run it > paired with other Perl apps the default installation is bound to give > you problems. To be honest, I have had no problems with a Debian based system, once I'd learned the ropes the first time through. But, then, 'slimserver-platforms' directly supports the subsequent packaging, so that probably helps. All done on the (cleanish) target system[1]. I have no experience of FreeBSD / Gentoo, etc., so I don't know/can't imagine what/why/where challenges emerge. [1] A white lie. I learned to make a minimal (clean) container in which to do the build. So, I have just built perl 5.32 binaries in a clean Debian 11 (Bullseye) container, running on my regular LMS system - Debian 10 (Buster), which has perl 5.28. So, I'm ready for the next upgrade... mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
mrw wrote: > > How often do you update your Perl ? That's the whole culprit, isn't it? If you do it every week you're bound to know all the pitfalls. The reality is that even with an average of once per year you end up hitting a wall with errors that at first don't seem to make any sense at all and once you figured it out you find yourself needing to manually clean up left and right because some other package on your system pulled in a different version of a module used by LMS and LoadModule matches the wrong .so to the .pm (which is what the cryptic error message was about). LMS is nice for Windows and dedicated (VM) systems, but if you run it paired with other Perl apps the default installation is bound to give you problems. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
wcattey wrote: > > It seems to me that the more we can get LMS to adopt "current upstream" > tool chain and support utilities, the less work for the LMS community to > keep the LMS fork maintained. > How much work has the LMS community expended in keeping the fork maintained ? By comparison with LMS itself, one might think rather little, if number of commits is a good measure. That may underestimate the work required to validate any updated packages against LMS on the supported Windows/*nix/macOS platforms/architectures. How often do you update your Perl ? Ive updated three times over the last five years or so. The build_me.sh worked just fine on my Debian based armel/arm5 system. The first time took a little bit of thought to work out how much of the build product I really needed, where to put it in the LMS tree, and how LMS sets up its @INC. Familiarity helped on the subsequent occasions. Is whats needed an up to date FreeBSD how to ? mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
Re: [SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
Honestly, the slimserver-vendor CPAN arch buildme is rubbish. I know because I referenced it for several years to build the arch dependent Perl libraries for version 1.18 up to 1.28. At some point I realized that many of the stuff being built actually already existed on my system, in a much newer version. And in fact the Perl module it created was available as an OS package as well. Therefore all of that compile time, which is significant on an armv5 cpu, was a complete waste of energy. It was 5 years ago that I started publishing my own set of armv5 support files for LMS on GitHub, but just 8 months ago when I managed to figure it out completely and make it fully compliant with my (Gentoo) system's update procedure while completely disregarding the slimserver-vendor project. I have since upgraded from Perl 5.30 first to 5.32 and next to 5.34 without encountering any issue at all. gordonb3's Profile: http://forums.slimdevices.com/member.php?userid=71050 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
[SlimDevices: SqueezeCenter] Can we update our CPAN fork footprint?
Recently I wanted to run LMS on our brand new FreeNAS FreeBSD 12 server. I discovered multiple ports and HOW-TOs for that platform. We grabbed the logitechmediaserver plug-in that installed with just few clicks on our default setup. It turned out that, although it was easy to install, that particular port had two issues: not using the LMS-fork of faad, breaking ALAC files, and not using the LMS-fork of the CPAN libraries. The latter means that if I update Perl in my LMS Jail, LMS will break. Indeed that happened to me a couple year ago, and I posted a forum article on how to recover from it. I now know about, (and showed the guy who did the port I'm running) the slimserver-vendor tree that contains a very complete set of CPAN libraries (and other stuff) that locks in all the nitty-gritty bits to keep LMS working. There's another competing FreeBSD port that includes a different fork of the CPAN libraries. Although I know that other fork has fewer modules, I don't know what the rationale was for picking them. Recognizing some guiding high-level principles: 1. Minimize the ongoing maintenance load both for individuals and the LMS community as a whole. 2. Maintain, as much as possible support for viable legacy platforms. 3. Make it as easy as possible for new people to adopt best practices. 4. Make it as easy as possible to do new stuff. 5. Minimize the additional effort required to avoid breaking old stuff. I would like to open a discussion about the current state of https://github.com/Logitech/slimserver-vendor/CPAN/ In https://github.com/Logitech/slimserver-vendor/pull/83, contributor simonef proposed a much shorter list of CPAN modules to lock in. It seems to me that the more we can get LMS to adopt "current upstream" tool chain and support utilities, the less work for the LMS community to keep the LMS fork maintained. However, there may be modules that simonef left out that have a material impact on legacy platforms and therefore should be retained in the fork. As a starting point, how about we amend the README in the CPAN directory to state which versions of LMS that tree supports? simonef seems to have drawn a line recently at 8.0 for his fork. As a next step, I'd like to understand why simonef removed the modules he removed, in his fork at: https://github.com/simonefil/slimserver-vendor I've started reading the history, and it looks like simonef has done a lot of work that might be beneficial to the canonical version at https://github.com/Logitech/slimserver-vendor/CPAN/, but also understanding all the work he has done does indeed seem like a non-trivial task. LMS 7.9 - 2xSB2, 2xBoom, 2xKodi, Ocean Digital WR2300S, Denon AVR-X6200W, SHIELD Android TV wcattey's Profile: http://forums.slimdevices.com/member.php?userid=7506 View this thread: http://forums.slimdevices.com/showthread.php?t=114975 ___ Squeezecenter mailing list Squeezecenter@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/squeezecenter
