| Summary: | media-sound/squeezecenter-7.3.3 has been updated to squeezebox server 7.4.0 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Nate Weibley <nweibley> |
| Component: | [OLD] Server | Assignee: | Joe Peterson (RETIRED) <lavajoe> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | gentoo, jaervosz, kdvgent, mail, martin, mirimiri66, peter, rajiv, stuart |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.logitechsqueezebox.com/support/download-squeezecenter.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 287264, 287857 | ||
| Bug Blocks: | |||
| Attachments: |
Failed build log for Comment #18
Update to support Perl 5.10.1 |
||
|
Description
Nate Weibley
2009-10-01 18:59:45 UTC
Thanks for the prod. Yes, I'm working on it now. As you've noted it will take a bit of work as they've changed the name (again! it's going to have to be "media-sound/squeezeboxserver", I think) and there are quite a few Perl dependency changes. Joe, you can assign this to me if you like. (In reply to comment #1) > Thanks for the prod. Yes, I'm working on it now. As you've noted it will take a > bit of work as they've changed the name (again! it's going to have to be > "media-sound/squeezeboxserver", I think) and there are quite a few Perl > dependency changes. > > Joe, you can assign this to me if you like. > Sorry, didn't mean for it to seem like a prod, just wanted to get it on the radar and tracked in case other people were thinking about it as well. If there is anything I or the community can do to help out let us know. (In reply to comment #2) > > Sorry, didn't mean for it to seem like a prod, just wanted to get it on the > radar and tracked in case other people were thinking about it as well. If there > is anything I or the community can do to help out let us know. > That's no problem at all - I meant 'thanks'! It'll probably take me a few days to get something basic working. I've been plugging away to try to tackle bug#251494 but I don't expect I'll be able to get that addressed for the 7.4.0 build. I will, however, have eradicated the build-perl-modules step this time around, I think. If you're interested you can keep an eye on my public git repository for this (http://github.com/hickinbottoms/squeezecenter-ebuild-for-gentoo) - I'll try to get a beta of the ebuild pushed to there as soon as it's basically working. Once it basically works I'll work on an update to migrate the old preferences over before submitting it to Portage. (In reply to comment #3) > If you're interested you can keep an eye on my public git repository for this > (http://github.com/hickinbottoms/squeezecenter-ebuild-for-gentoo) - I'll try to > get a beta of the ebuild pushed to there as soon as it's basically working. > Once it basically works I'll work on an update to migrate the old preferences > over before submitting it to Portage. > Stuart I've been watching your develop-7.4 branch and noticed a few recent commits that seem like you've got a functional ebuild. Is this now functional/beta enough for me to try with reasonable odds I'll get a web interface running and can spend some time hunting for bugs in the new SBS? Yes, generally the ebuild does seem to be working. There are a couple of things with it, though: 1. It won't migrate your existing SqueezeCenter settings yet. 2. There are a couple of Perl modules that it depends on that are not yet in Portage. The first I suspect you're happy with (it might even be an advantage while it's in beta). The second concerns the following modules: 1. Audio::Scan (requested in bug#287264) 2. EV (requested in bug#287857) If you can build those two modules yourself (app-portage/g-cpan might help with that, but I think I had to hand-roll EV in the end), then you should definitely be able to install it and get it working with the current beta ebuild with minimal difficulties. You'll notice, though, that you'll need quite a few more unstable Perl packages in your /etc/portage/package.keywords file. It might help if you could drop a comment in those two bugs as well (I'd make this dependent on them but as this bug is not assigned to me at the moment). Stuart, let me know when you've got something ready for the new version. Is the official new name "Squeeze Box Server"? It makes a long name "squeezeboxserver" - which is ashame. But if that's the name, we'll have to use it. (In reply to comment #5) > If you can build those two modules yourself (app-portage/g-cpan might help with > that, but I think I had to hand-roll EV in the end), then you should definitely > be able to install it and get it working with the current beta ebuild with > minimal difficulties. You'll notice, though, that you'll need quite a few more > unstable Perl packages in your /etc/portage/package.keywords file. > > It might help if you could drop a comment in those two bugs as well (I'd make > this dependent on them but as this bug is not assigned to me at the moment). > You're dead right... squeezeboxserver ebuild works great but as expected the server must be reconfigured (though admittedly due to the changes in the GUI/server this may not be a terrible option as long as saving prefs is also an option). Audio:Scan pulled in through g-cpan like a breeze but needs it's own ebuild I agree... an EV reuquired the CPAN console due to YAML weirdness and inotify grief. Nonetheless the squeezeboxserver ebuild was flawless and the server is working great. Thanks, this bug is well on it's way to being closed! (In reply to comment #6) > Stuart, let me know when you've got something ready for the new version. Is > the official new name "Squeeze Box Server"? It makes a long name > "squeezeboxserver" - which is ashame. But if that's the name, we'll have to > use it. > Yes, will do. It's kind of dependent on those two bugs this is now dependent on (to avoid bundling even more CPAN modules) but, if there's no progress on that in a while I can look at bundling them in as well. Re 'squeezeboxserver' - yes, it's a biggie but that's the name they're currently giving it. This also matches the name of the Debian and other packaged builds they produce so I think that's what it should be for consistency, unfortunately. Stuart, Anything I can do to make this move? A long story: Logitec pushed out the the latest squeezebox update (to 7.4), but it will only work with the "new" squeeze-box-server. So my squeezebox became stuck in a never ending upgrade-oops-downgrade oops-upgrade... cycle trying to work with squeezecenter and wanting to upgrade. I killed (emerge -C) squeezecenter as it is now useless and, in addition, causes the upgrade-downgrade problem. I tried to install squeezeboxserver from your page, most of it seemed to roll out OK but I couldn't get it to work (perhaps I do not know how to "hand roll" EV correctly). So for now, I cloned a W2k virtual machine and installed windoz squeezeboxserver. Pretty disgusting, but I can listen to music again. I wish I had a better understanding of the issues involved, they seem philosophical to me. But, if there is something I can do to help, please let me know. And thanks for being a developer. (In reply to comment #9) > I tried to install squeezeboxserver from your page, most of it seemed to roll out OK but I > couldn't get it to work (perhaps I do not know how to "hand roll" EV > correctly). Quick 101, assuming you know how to add an overlay and checkout the git branch. You need to emerge g-cpan Then you can run: g-cpan -i Audio::Scan (this will install Audio::Scan via an automatically generated ebuild stored in an overlay) Next to install EV open a console and start the cpan console: cpan install EV (if it fails to test it's an inotify issue, run force install EV) _Then_ test the new ebuild and it should work. Sorry it's taking so long. It doesn't look like those two dependent bugs are going to get closed soon, but you could drop a comment into them (bug#287264, bug#287857) to try to get them moved on a little. In the meantime I'll try to get those two Perl packages bundled with this ebuild - it's messy and will irritate the problem in bug#251494, but I don't see an alternative at the moment. So, I'll have a crack at that in the next few days and try to get a version of the ebuild together that at least works, even if it isn't entirely 'clean'. Note that it'll be for Squeezebox Server 7.4.1 as that is now out, which shows how slow I've been! (In reply to comment #9) > Stuart, > > Anything I can do to make this move? A long story: Logitec pushed out the the > latest squeezebox update (to 7.4), but it will only work with the "new" > squeeze-box-server. So my squeezebox became stuck in a never ending > upgrade-oops-downgrade oops-upgrade... cycle trying to work with squeezecenter > and wanting to upgrade. I killed (emerge -C) squeezecenter as it is now > useless and, in addition, causes the upgrade-downgrade problem. I tried to > install squeezeboxserver from your page, most of it seemed to roll out OK but I > couldn't get it to work (perhaps I do not know how to "hand roll" EV > correctly). So for now, I cloned a W2k virtual machine and installed windoz > squeezeboxserver. Pretty disgusting, but I can listen to music again. I wish > I had a better understanding of the issues involved, they seem philosophical to > me. But, if there is something I can do to help, please let me know. And > thanks for being a developer. > Stuart, I spread my whining (as comments) to both the bugs (EV / Audio). I kind of understand and respect the concept for not bundling stuff as it is not the Gentoo way. I would be happy using your git repository build -- as long as I can make it work -- if putting this stuff in portage proper is an issue. Again, thanks I think it's a matter of when this gets into Portage, not if. I'll work on bundling EV/Audio::Scan and if those bugs move on in the meantime I'm more than happy to back that out. I'll report back here when the ebuild is ready - you can separately monitor my git repository if you're interested in the intermediate development - I'll avoid duplicating that here to reduce the noise. (In reply to comment #12) > Stuart, > > I spread my whining (as comments) to both the bugs (EV / Audio). I kind of > understand and respect the concept for not bundling stuff as it is not the > Gentoo way. I would be happy using your git repository build -- as long as I > can make it work -- if putting this stuff in portage proper is an issue. > > Again, thanks > I got it working. I did not initially roll out EV in the manner suggested by Nate. After following his directions (actually much simpler than what I did), 59 perl modules later it fired up and works. Now I can shut down the windoze VirtualBox! Thanks Stuart and Nate. I've now got to the stage where the server starts and seems to serve music. I've not done much testing but it appears basically working. Could those able to test from my github repository give this version a try? http://github.com/hickinbottoms/squeezecenter-ebuild-for-gentoo/tree/develop-7.4/stage/ If this works OK I'll think about the migration of old SqueezeCenter settings and hopefully get it moved to the Portage tree without the "beta" mark. I have tried to build it but on my ppc-gentoo machine the ebuild fails at
cp -r CPAN/arch "${D}/usr/lib/squeezeboxserver/CPAN" || die "Unable to install compiled CPAN modules"
and if i check under "work/squeezeboxserver-7.4.1-28947-noCPAN/CPAN/" there is no arch directory.
(In reply to comment #15)
> ...
> Could those able to test from my github repository give this version a try?
> ..
Sorry you're having trouble. That's odd - that directory is present (but empty) in the Squeezebox Server tarball so that line shouldn't fail. Could you try the latest version (I've made the Perl module compilation temporarily more verbose to try to track down some problems) and capture a log with: emerge squeezeboxserver 2>&1 | tee build.log and attach that log so I could take a look? Stuart (In reply to comment #16) > I have tried to build it but on my ppc-gentoo machine the ebuild fails at > cp -r CPAN/arch "${D}/usr/lib/squeezeboxserver/CPAN" || die "Unable to install > compiled CPAN modules" > > and if i check under "work/squeezeboxserver-7.4.1-28947-noCPAN/CPAN/" there is > no arch directory. > > (In reply to comment #15) > > ... > > Could those able to test from my github repository give this version a try? > > .. > I have a similar problem with CPAN/arch directories on x86 - the ebuild fails with the following messages >>> Install squeezeboxserver-7.4.1_beta into /tmp/portage/media-sound/squeezeboxserver-7.4.1_beta/image/ category media-sound cp: cannot stat `CPAN-arch/*': No such file or directory ERROR: media-sound/squeezeboxserver-7.4.1_beta failed. * Call stack: * ebuild.sh, line 49: Called src_install * environment, line 2440: Called die * The specific snippet of code: * cp -r CPAN-arch/* "${D}/usr/lib/squeezeboxserver/CPAN/arch" || die "Unable to install compiled CPAN modules"; * The die message: * Unable to install compiled CPAN modules Looking in /var/tmp/portage/media-sound/squeezeboxserver-7.4.1_beta/work/squeezeboxserver-7.4.1-28947-noCPAN there is no CPAN-arch/ directory, but I do have CPAN/arch/ which is empty. I had a bit of a dig around in the ebuild, but couldn't really see what I should do to fix this (properly!), so I commented out the three lines in that area (see diff below) - I don't have CPAN-pm/ directory either, or CPAN/pm so I figured that line would be the next to fail! The ebuild then installed, but when I tried to start squeezeboxserver it failed because EV and Audio::Scan weren't installed. So I installed both of these as per the instructions in Comment #10 and now it seems to be working ok. All my players have upgraded firmware, playing music works, new BBC App works, 3rd party BBC IPlayer plugin works (after I disabled AAC in it's settings), Podcast app works. Thanks for your efforts putting this ebuild together :-) Will try to attach a build.log. --- squeezeboxserver-7.4.1_beta.ebuild-workingRL 2009-11-08 09:43:35.000000000 +0000 +++ squeezeboxserver-7.4.1_beta.ebuild 2009-11-08 11:04:36.000000000 +0000 @@ -230,9 +230,9 @@ cp -r lib/* "${D}/${LIBDIR}" || die "Unable to install architecture-dependent files" # Install compiled Perl modules because of bug#287264 and bug#287857. - #dodir "/usr/lib/squeezeboxserver/CPAN/arch" - #cp -r CPAN-arch/* "${D}/usr/lib/squeezeboxserver/CPAN/arch" || die "Unable to install compiled CPAN modules" - #cp -r CPAN-pm/* "${D}/usr/share/squeezeboxserver/CPAN" || die "Unable to install compiled CPAN modules" + dodir "/usr/lib/squeezeboxserver/CPAN/arch" + cp -r CPAN-arch/* "${D}/usr/lib/squeezeboxserver/CPAN/arch" || die "Unable to install compiled CPAN modules" + cp -r CPAN-pm/* "${D}/usr/share/squeezeboxserver/CPAN" || die "Unable to install compiled CPAN modules" Created attachment 209622 [details] Failed build log for Comment #18 (In reply to comment #19) > Created an attachment (id=209622) [details] > Failed build log for Comment #18 > Thanks for that. Having looked at the attachment it appears that the problems are caused by one of the built-in tests for EV failing (Perl modules are generally packaged with tests so that they can self-test before installing). That means the results aren't there to install (which is why there's no arch-pm directory etc). The offending output is: "Failed tests: 6-7, 9" near the end. Unfortunately a build problem with EV is not something I can easily debug as I don't know what those test failures point to (I can see the test source, but it's pretty impenetrable). It's odd that it builds when you manually build it, though (does that run through the test step, I wonder?) Looking at CPAN it looks like you're not the only one with that problem - see here: http://rt.cpan.org/Public/Bug/Display.html?id=51172 It might be worth contacting the author to try to see whether there was an obvious reason for that failure (see contact details for that module on CPAN). (In reply to comment #20) Ah, yes, I think I did have to do a "force install" as suggested in Comment #10 because the tests failed and so it didn't install anything. That just says that it's an "inotify" issue (whatever that might mean :-) ), but it seems to work ok without anyway... > Looking at CPAN it looks like you're not the only one with that problem - see > here: > http://rt.cpan.org/Public/Bug/Display.html?id=51172 > > It might be worth contacting the author to try to see whether there was an > obvious reason for that failure (see contact details for that module on CPAN). Interesting - looks like whoever posted that wont be getting a response based on the start of that automated-looking reply! You might have something there - do you have inotify support compiled into your kernel? The following might identify that: zcat /proc/config.gz | grep INOTIFY If that's the reason I could look at making it ignore errors for the tests of that module. (In reply to comment #21) > Ah, yes, I think I did have to do a "force install" as suggested in Comment #10 > because the tests failed and so it didn't install anything. That just says > that it's an "inotify" issue (whatever that might mean :-) ), but it seems to > work ok without anyway... > ... (In reply to comment #22) > You might have something there - do you have inotify support compiled into your > kernel? The following might identify that: > > zcat /proc/config.gz | grep INOTIFY > > If that's the reason I could look at making it ignore errors for the tests of > that module. Hmm, it would seem that I do: robert@quad ~ $ zcat /proc/config.gz |grep -i inot CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y robert@quad ~ $ cat /proc/version Linux version 2.6.31.5 (root@quad) (gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) ) #1 SMP PREEMPT Sat Nov 7 16:21:11 GMT 2009 OK - I've disabled the CPAN module tests for EV - if you pull an update from the git repository you should get that version. This isn't ideal, but most people install CPAN modules from Portage without running those tests and so it's not really any worse than that. (In reply to comment #23) > (In reply to comment #22) > > You might have something there - do you have inotify support compiled into your > > kernel? The following might identify that: > > > > zcat /proc/config.gz | grep INOTIFY > > > > If that's the reason I could look at making it ignore errors for the tests of > > that module. > > Hmm, it would seem that I do: > > robert@quad ~ $ zcat /proc/config.gz |grep -i inot > CONFIG_INOTIFY=y > CONFIG_INOTIFY_USER=y > > robert@quad ~ $ cat /proc/version > Linux version 2.6.31.5 (root@quad) (gcc version 4.3.4 (Gentoo 4.3.4 p1.0, > pie-10.1.5) ) #1 SMP PREEMPT Sat Nov 7 16:21:11 GMT 2009 > Building fails with NFS mounted Portage tree with noexec: * Building bundled Perl modules (some warnings are normal here)... /var/tmp/portage/media-sound/squeezeboxserver-7.4.1/temp/environment: /usr/portage/media-sound/squeezeboxserver/files/build-modules.sh: /bin/bash: bad interpreter: Permission denied (In reply to comment #25) > Building fails with NFS mounted Portage tree with noexec: > > * Building bundled Perl modules (some warnings are normal here)... > /var/tmp/portage/media-sound/squeezeboxserver-7.4.1/temp/environment: > /usr/portage/media-sound/squeezeboxserver/files/build-modules.sh: /bin/bash: > bad interpreter: Permission denied Interesting. Stuart, this could probably be easily fixed by copying the script to the work area first. I suspect directly executing out of the portage tree is somewhat a no-no anyway. (In reply to comment #26) > (In reply to comment #25) > > Building fails with NFS mounted Portage tree with noexec: > > > > * Building bundled Perl modules (some warnings are normal here)... > > /var/tmp/portage/media-sound/squeezeboxserver-7.4.1/temp/environment: > > /usr/portage/media-sound/squeezeboxserver/files/build-modules.sh: /bin/bash: > > bad interpreter: Permission denied > > Interesting. Stuart, this could probably be easily fixed by copying the script > to the work area first. I suspect directly executing out of the portage tree > is somewhat a no-no anyway. > Yes, I think you're right Joe. I'll take a look at what other packages do and do the same - at the very least it could just be run as an argument to "bash" to avoid trying to directly execute the file. Also with just a bit of hacking you can use another mysql server, so you might want to make the following change to the init script: - need net mysql + need net + use mysql ie. modify /var/lib/squeezeboxserver/prefs/squeezeboxserver.prefs dbusername: squeezecenter dbpassword: password dbsource: dbi:mysql:hostname=mysqlservername;database=squeezecenter Created attachment 211722 [details, diff] Update to support Perl 5.10.1 This is a patch to the build-modules.sh script in files to add support for Perl 5.10.1 which is what I got from portage for a new build this week. Without this patch I get the same error as in comment 18 - no perl binary is found and the modules build fails silently. As well as explicit perl 5.10.1 support I have also added a sanity check and error message in the case where no perl binary is found, this should at least help with future debugging. Its early days, but squeezecenter seems to be working with perl 5.10.1 so far... (In reply to comment #28) > Also with just a bit of hacking you can use another mysql server, so you might > want to make the following change to the init script: > > - need net mysql > + need net > + use mysql > > ie. modify /var/lib/squeezeboxserver/prefs/squeezeboxserver.prefs > dbusername: squeezecenter > dbpassword: password > dbsource: dbi:mysql:hostname=mysqlservername;database=squeezecenter > Thanks for that - yes I think that's a good idea. I'll store that up for the next update. Thanks for that - I'll take a look at including that for the next update. I believe that Logitech build the Windows versions with perl 5.10 so I would expect it to work OK. Thanks again for that. (In reply to comment #29) > Created an attachment (id=211722) [details] > Update to support Perl 5.10.1 > > This is a patch to the build-modules.sh script in files to add support for Perl > 5.10.1 which is what I got from portage for a new build this week. > > Without this patch I get the same error as in comment 18 - no perl binary is > found and the modules build fails silently. > As well as explicit perl 5.10.1 support I have also added a sanity check and > error message in the case where no perl binary is found, this should at least > help with future debugging. > Its early days, but squeezecenter seems to be working with perl 5.10.1 so > far... > Masking for removal in 30 days. |
