I was able to hack the current 7.5.4 ebuild for 7.5.5 (which has also been released) but in 7.6.0 the perl dependencies and associated build script have changed significantly enough, for me not even trying. 7.5.5 should be easy, 7.6.0 would be great. It is somewhat problematic running 7.5.4/5, because all Squeezeboxes I have (Radio + Touch) want to update to 7.6.0 but then after connecting to my GenToo server want to "upgrade" to 7.5.4/5 and upgrades are only cancelable through tricks (alarm button on Radio, remote on Touch). I guess that's a firmware problem (just checking if the version is different, not newer), but if this can be fixed server side (e.g. not offering/installing firmware updates with the ebuild at all), maybe you can help. Reproducible: Always Steps to Reproduce: emerge -p squeezeboxserver Optional: connect Squeezbox Radio/Touch using firmware 7.6.0 and it will want to "upgrade" to 7.5.4/5 Actual Results: offered 7.5.4 Expected Results: offer 7.6.0 http://www.mysqueezebox.com/download
7.6.1 has also been released...
It's on my radar to produce an updated ebuild, but am finding it difficult to make the time at the moment. However, I haven't forgotten and will try to make some progress on 7.6.1 (or 7.6.2, if they've released that...), soon.
Created attachment 291397 [details] squeezeboxserver 7.6.1 ebuild
Created attachment 291399 [details, diff] squeezeboxserver-7.6.1-build-perl-modules-gentoo.patch
Created attachment 291401 [details] updated prefs file containing 'dbtype'
Created attachment 291403 [details] build-modules-7.6.1.sh
Created attachment 291405 [details] ebuild for new dependency: dev-perl/Image-Scale
Created attachment 291407 [details, diff] patch to Image::Scale for libpng 1.5 support
The attached ebuild only handles SqueezeboxServer 7.6 with a MySQL installation, but upstream has made SQLite the default again. A perfect ebuild would accept the proper use flags to control dependencies and create the proper preferences files for SQLite, but I was upgrading from a previous version and had no interest in creating a new SQLite DB from scratch Without 'dbtype: MySQL' (case-sensitive) in /etc/squeezeboxserver/prefs/server.prefs, launching squeezeboxserver 7.6.0 would cause the DB preferences to be overwritten with SQLite defaults. This doesn't appear to be a problem anymore with 7.6.1, but I haven't tested it thoroughly. Back up your configuration files and/or read the warnings before restarting the server after upgrading.
Thanks for the bits of the ebuild. I'm looking at this at the moment, with a view to supporting both mysql and sqlite via USE flags. I'm hoping to do some work on that this weekend, and I'll look at the changes you've made in the attached ebuild files and see which bits to roll in. Stay tuned...
I've raised a separate bug#389739 for the addition of the Image::Scale ebuild. This is necessary so the ebuild gets to the Perl ebuild devs.
I've raised bug#389747 for an update to the dev-perl/DBD-SQLite ebuild to 1.34. I won't be able to incorporate the SQLite functionality until then (this is the version Logitech have tested with, and are shipping with the server, so I'm reluctant to guess it'll work with older versions).
I have submitted working Image::Scale ebuilds and DBD-SQLite has been bumped and closed. You should be ready to go on this.
Stuart, do you have everything you need for this one now?
Unfortunately, 7.6.1 is extremely difficult to integrate into gentoo. It requires a package for libmediascan, which is a library that has not officially been released. I found a copy hidden in their SVN here: http://svn.slimdevices.com/repos/slim/7.7/trunk/vendor/CPAN/libmediascan-0.1.tar.gz Then once you have this, you need to build a perl lib Scan.so that links to it. It's nasty. For now I have set up a Centos 5.7 OpenVZ container and just installed the RPMs for now. You could also use LXC for this. Long-term, it may be a better strategy to try to install the necessary stuff to run the binaries, and create a logitechmediaserver-bin ebuild.
(In reply to comment #15) > Unfortunately, 7.6.1 is extremely difficult to integrate into gentoo. It > requires a package for libmediascan, which is a library that has not officially > been released... Interesting - yes, it seems that this package has always been a bear. We (well, Stuart, really) have done a lot of work to get it "Gentoo-ified" in terms of getting the various perl modules, etc., stabilized and working with the package, but the problem has always been that this is not how upstream intends it to build. They rely on bundling, since then there is total control over versions, etc. It seems we are chasing this goal, but too bad to give up on it unless we'll always be a few steps behind.
Any news on this package? Is anyone still working on it? Personally I'd prefer to see this as a binary package...
I think a binary package is the way to go. The problems this pkg currently has are solvable, but the current strategy of putting all deps in ebuilds provides little to no value and will continue to be a maintenance liability going forward. In other words, +1 on the binary pkg.
(In reply to comment #17) > Any news on this package? Is anyone still working on it? > Personally I'd prefer to see this as a binary package... Stuart Hickinbottom is the proxy maintainer for this package. Hey Stuart, any thoughts on this as a binary package, as Daniel recommends?
(In reply to comment #19) > (In reply to comment #17) > > Any news on this package? Is anyone still working on it? > > Personally I'd prefer to see this as a binary package... > > Stuart Hickinbottom is the proxy maintainer for this package. > Hey Stuart, any thoughts on this as a binary package, as Daniel recommends? Hello Joe. No excuses but I've been a bit off the radar with work commitments for far too long. I'd definitely like to have a crack at a binary build - I'm not sure I know what's involved in that yet but I'll take a look around at the documentation and other example packages. I'll be honest and say I've not been looking forward to producing updated ebuilds as it really is a grind with all the dependencies, and it just seems to get worse on each release. I'll take a look at the binary approach at producing a -bin flavour ebuild. I've noticed that while I've been dithering they're up to 7.7.2 now so I'll start with that. Apologies, everyone, for the delays.
(In reply to comment #20) > I'd definitely like to have a crack at a binary build - I'm not sure I know > what's involved in that yet but I'll take a look around at the documentation > and other example packages. > > I'll be honest and say I've not been looking forward to producing updated > ebuilds as it really is a grind with all the dependencies, and it just seems > to get worse on each release. Stuart, great to hear from you, and glad to have your weigh-in on the binary thing. Yeah, perhaps time to stop fighting with the dependencies on this package. I have not built a binary either, but there are some good examples in the tree, so that may be a help. Let me know what you find! And I'll be glad to help test when you think you have something. I've been busy as well lately.
(In reply to comment #21) > Stuart, great to hear from you, and glad to have your weigh-in on the binary > thing. Yeah, perhaps time to stop fighting with the dependencies on this > package. I have not built a binary either, but there are some good examples > in the tree, so that may be a help. Let me know what you find! And I'll be > glad to help test when you think you have something. I've been busy as well > lately. I feel slightly re-invigorated by this and have set up a new github repository for the development that interested parties can nose into: https://github.com/hickinbottoms/logitechmediaserver-bin-ebuild-for-gentoo/tree/feature/7.7.2 There's nothing much there yet but I'll push to this when there's something interesting. I've started by looking through some other *-bin ebuilds got inspiration and reading the dev handbook and FHS on the use of /opt /etc/opt and /var/opt. Hopefully I'll have actually produced something soon. I routinely run the development LMS version (including its binaries) without any compilation or massive package dependencies so it should definitely work.
Stuart, on behalf of all the users I would like to say that your work on this package is very much appriciated! I hope the binary build won't give you too much trouble.
(In reply to comment #23) > Stuart, on behalf of all the users I would like to say that your work on > this package is very much appriciated! I hope the binary build won't give > you too much trouble. Thanks for the kind words. For the benefit of the bug I've got a beta of the 7.7.2 ebuild working. I must say that a binary ebuild is a breath of fresh air after chasing down all those Perl dependencies. I'm passing this to Joe (via email) for a review so we'll see how we go.
New package media-sound/logitechmediaserver-bin added. Thanks, Daniel, for the advice regarding dong a binary package, and thanks, Stuart, for putting this one together!
Oh well, not again! There do exist architectures besides x86 and amd64. !!! All ebuilds that could satisfy "media-sound/logitechmediaserver-bin" have been masked. !!! One of the following masked packages is required to complete your request: - media-sound/logitechmediaserver-bin-7.7.2::gentoo (masked by: missing keyword) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. mac ~ # ~thomas/bin/findKeywords.sh media-sound/logitechmediaserver-bin KEYWORDS="~amd64 ~x86" Replacing this package with a binary-only one is not the greatest option on earth since it will leave everybody with non-x86 platforms in the dust. Why not simply leave this package as is and put it into not-maintained state? This would at least allow everybody to continue using it instead of leaving everybody with a non-x86 system with a useless brick called Squeezebox?
(In reply to comment #26) > Oh well, not again! There do exist architectures besides x86 and amd64. > ... snip Hello Thomas - what architecture do you have? We've only provided keywords for x86 and amd64 since they're the only ones we've tested, but the binary package from Logitech includes support for the following: arm-linux darwin i386-freebsd-64int i386-linux (including amd64) powerpc-linux sparc-linux If it's in the above list then if you drop me an email with that info I can get you a test version of the ebuild with that arch enabled for you to test. Also, if you've already got squeezeboxserver installed then it'll stay installed and working; it's just masked so that it'll be avoided for future new installs.
(In reply to comment #27) > Hello Thomas - what architecture do you have? We've only provided keywords > for x86 and amd64 since they're the only ones we've tested, but the binary > package from Logitech includes support for the following: > > arm-linux > darwin > i386-freebsd-64int > i386-linux (including amd64) > powerpc-linux > sparc-linux I am running powerpc-linux (uname -a: Linux mac 3.3.2 #1 PREEMPT Sun Apr 15 09:28:59 CEST 2012 ppc 7447A, altivec supported PowerMac10,1 GNU/Linux) > If it's in the above list then if you drop me an email with that info I can > get you a test version of the ebuild with that arch enabled for you to test. Yes, it seems like we PPC people hit a lucky streak this time. :-) > Also, if you've already got squeezeboxserver installed then it'll stay > installed and working; it's just masked so that it'll be avoided for future > new installs. Yes, it is running just fine on my PowerPC box. So in the end it is possible to keep it installed even when I routinely run a world update? I was not aware of that and thought that it would get erased automatically when I then clean the system afterwards. Thanks for clarifying. I would indeed appreciate the email and give it a try, Thanks for caring! Cheers, Thomas
(In reply to comment #28) > (In reply to comment #27) > > If it's in the above list then if you drop me an email with that info I can > > get you a test version of the ebuild with that arch enabled for you to test. > > Yes, it seems like we PPC people hit a lucky streak this time. :-) Thomas, what you may want to do is create your own overlay on your machine, copy the new ebuild to this, and add a keyword for your arch. See http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5 if you need help with this process. This way, you can play with the ebuild and have to do this in /usr/portage. Just be sure you remember to remove your version of the ebuild later, once your arch gets keyworded in the official tree. > > Also, if you've already got squeezeboxserver installed then it'll stay > > installed and working; it's just masked so that it'll be avoided for future > > new installs. > > Yes, it is running just fine on my PowerPC box. So in the end it is > possible to keep it installed even when I routinely run a world update? I > was not aware of that and thought that it would get erased automatically > when I then clean the system afterwards. Thanks for clarifying. The only issue here is that once you remove the old package, you won't be able to re-install it. Also, since the new -bin ebuild blocks the old, you'll have to remove the old one before trying the new, etc. This is another reason an overlay of your own will help: copy the existing squeezeboxserver ebuilds into your own overlay. Then you'll have them forever. As for why we went to a -bin package, it turned out to be quite difficult to correctly do a source build for the new version. We tried for a long time to keep the package a source one, but the way upstream packages the software made it more and more troublesome. If/when Logitech designs a more standard build (without all of the bundling and strict version requirements for perl modules, etc.) we can consider going back to a source package.
(In reply to comment #29) > Thomas, what you may want to do is create your own overlay on your machine, > copy the new ebuild to this, and add a keyword for your arch. See > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=5 if you > need help with this process. > > This way, you can play with the ebuild and have to do this in /usr/portage. > > Just be sure you remember to remove your version of the ebuild later, once > your arch gets keyworded in the official tree. > OK, did that. After Perl got rebuilt (missing ithreads USE flag), it installed all right. > The only issue here is that once you remove the old package, you won't be > able to re-install it. Also, since the new -bin ebuild blocks the old, > you'll have to remove the old one before trying the new, etc. I created a bin-pkg on my system and keep it in a safe place if it does not work out. > This is another reason an overlay of your own will help: copy the existing > squeezeboxserver ebuilds into your own overlay. Then you'll have them > forever. OK, did that, too. > As for why we went to a -bin package, it turned out to be quite difficult to > correctly do a source build for the new version. We tried for a long time > to keep the package a source one, but the way upstream packages the software > made it more and more troublesome. If/when Logitech designs a more standard > build (without all of the bundling and strict version requirements for perl > modules, etc.) we can consider going back to a source package. Yeah, I figured that already reading through the comments here. So, now for the real stuff. The startup fails with the following message: The following modules failed to load: EV JSON::XS YAML::XS Sub::Name I got that after I ran the server standalone with all the options from the init.d script added. BTW there is an empty option line in the init script. Any idea what I could do? Thx a lot! Cheers, Thomas
(In reply to comment #30) > ... snip > So, now for the real stuff. The startup fails with the following message: > > The following modules failed to load: EV JSON::XS YAML::XS Sub::Name > > I got that after I ran the server standalone with all the options from the > init.d script added. BTW there is an empty option line in the init script. The empty option line is important since it separates the parameters for start-stop-daemon from those on slimserver.pl. I might have missed something but why do you need to try to start it manually rather than through the init script - is this just to try to debug the startup failure? Try setting the --d_startup option in /etc/conf.d/logitechmediaserver as per the comment at the end of that file and trying to start it again through the initscript. It should dump a load of information about what it's trying to load from where that should help - if you could attach that to this bug (or, ideally, raise a new one since it's about the new package) I could take a look.
(In reply to comment #31) > I might have missed something but why do you need to try to start it > manually rather than through the init script - is this just to try to debug > the startup failure? Because starting it through the initscript just fails. :-) So starting it manually might give me an indication of what is wrong. > Try setting the --d_startup option in /etc/conf.d/logitechmediaserver as per > the comment at the end of that file and trying to start it again through the > initscript. It should dump a load of information about what it's trying to > load from where that should help - if you could attach that to this bug (or, > ideally, raise a new one since it's about the new package) I could take a > look. Done it but that changed nothing. No additional output! Still won't start as daemon without a notice. Running manually again results in the same error message about the non-functional Perl modules. I guess the problem with the non-functional Perl modules occurs before any debugging output can be made. Cheers, Thomas
(In reply to comment #32) > (In reply to comment #31) > > I might have missed something but why do you need to try to start it > > manually rather than through the init script - is this just to try to debug > > the startup failure? > > Because starting it through the initscript just fails. :-) So starting it > manually might give me an indication of what is wrong. > > > > Try setting the --d_startup option in /etc/conf.d/logitechmediaserver as per > > the comment at the end of that file and trying to start it again through the > > initscript. It should dump a load of information about what it's trying to > > load from where that should help - if you could attach that to this bug (or, > > ideally, raise a new one since it's about the new package) I could take a > > look. > > Done it but that changed nothing. No additional output! Still won't start > as daemon without a notice. Running manually again results in the same > error message about the non-functional Perl modules. I guess the problem > with the non-functional Perl modules occurs before any debugging output can > be made. > > Cheers, > Thomas What if you run it manually with "--d_startup"? I would expect some kind of output from that. Could you try that and give the output (which should be quite a lot of Perl-looking stuff), and if not copy/paste the exact command you're running from the terminal to try to start it together with the ID of the user you are when you're running that. Thanks.
(In reply to comment #32) > ... snip Furthermore, you did run "perl-cleaner --modules ; perl-cleaner --force --libperl" as per the instructions when you re-emerged perl with ithreads enabled didn't you...?
(In reply to comment #34) > (In reply to comment #32) > > ... snip > > Furthermore, you did run "perl-cleaner --modules ; perl-cleaner --force > --libperl" as per the instructions when you re-emerged perl with ithreads > enabled didn't you...? After having the olde squeezeboxserver uninstalled, I asked emerge to clean the system from unused Perl modules. Then I ran a world update including a full revdep rebuild and then the update of the Perl modules. The system itself is in perfect condition and 100% healthy. Output of the run is attached. From a first glimpse at the log tt seems to me that logitechmediaserver still uses some Perl modules from the system which are incompatible. Thanks again for your help! Cheers, Thomas
Created attachment 309247 [details] Logfile for logitechmediaserver on a PPC system
(In reply to comment #33) > you're running from the terminal to try to start it together with the ID of > the user you are when you're running that. Thanks. Running it manually as logitechmediaserver user per su does not work because the account is locked. The executed script is the init.d script sans the dæmon stuff plus su'ing the command as logitechmediaserver user: mac tmp # ./logitechmediaserver This account is currently not available. Hence I run it as root instead to have full access to everything. Cheers, Thomas
Just to round off the PPC discussion in case anyone finds it through searching, I've had quite a lot of communication with Thomas and in summary: 1. Logitech only bundle powerpc CPAN module binaries that are built for Perl compiled for 64bit integers (ie perl build with -D64bitint). Note this is a 32bit Perl but with support for longer integers. 2. Gentoo doesn't currently support building Perl in this mode. So, it's not possible to use the binary logitechmediaserver build directly on PowerPC. I've raised a bug to request Logitech provide 32bit integer support for powerpc: http://bugs.slimdevices.com/show_bug.cgi?id=17954 In the meantime, Thomas has managed to build the CPAN modules himself and add those to the binary build, so that remains an option, although it's a little involved.
(In reply to comment #38) Without Stuart's invaluable work, I would not have figured that out at all. Kudos to Stuart! > In the meantime, Thomas has managed to build the CPAN modules himself and > add those to the binary build, so that remains an option, although it's a > little involved. In order to return something to the community, a tarball that contains all the necessary binaries for the 32 bit powerpc architecture can be downloaded from here [http://www.senmut.net/~thomas/Private/Soft/logitechmediaserver/powerpc-linux-thread-multi.tar.bz2]. Just unpack it to /opt/logitechmediaserver/CPAN and LMS should be ready to go. Thanks again to Stuart! Cheers, Thomas
Migrating my squeezeboxserver setup to logitechmediaserver-bin running on hardened resulted in PAX throwing "denied RWX mprotect" errors. So for now I'm back on squeezeboxserver.
Sune, since this bug is closed, could you open a new bug for this. Also, could you include the output you are getting (that shows the errors)? I am not familiar with hardened, but I do not see anything unusual being done in the config script, so it would be very helpful to see where it is failing, exactly.
I reverted back to the squeezeboxserver ebuild and lost the dmesg output:-( AFAIR it complained about scan.so.
