|
Description
TGL
2004-12-08 12:46:43 UTC
Created attachment 45556 [details]
media-sound/slimserver-5.4.0
Created attachment 45557 [details, diff]
files/slimserver-5.4.0--drop_Movie.patch
Created attachment 45558 [details, diff]
files/slimserver-5.4.0--playlistdir_option.patch
Created attachment 45559 [details]
files/slimserver.confd
Created attachment 45560 [details]
files/slimserver.initd
Created attachment 45561 [details]
dev-perl/Audio-FLAC-Header-1.2
Created attachment 45563 [details]
dev-perl/Audio-Musepack-0.02
Created attachment 45564 [details]
dev-perl/Ogg-Vorbis-Header-PurePerl-0.07
Created attachment 45565 [details]
dev-perl/Tie-RegexpHash-0.12.ebuild
Dear perl devs, CCing you cause i guess adding new modules would need your approval. assigning to perl... once the modules are in portage, please assign back to sound@. sound@ is very understaffed right now, so I can't gurantee when this can get added. If you're interested in helping out with that, pleasse let me know. Created attachment 45615 [details, diff]
media-sound/slimserver-5.4.0
Minor rework on some dirs owning and perms, things like that.
Created attachment 45616 [details, diff]
files/slimserver.confd
Created attachment 45617 [details, diff]
files/slimserver.initd
With more testing i've seen several bugs that are due to the use of vanilla CPAN perl modules in place of the ones provided by the slimserver archive, which were actually slightly modified. So I will have to recheck everything and make the necessary changes. The perl ebuilds i've attached may not be of any use after this changes, i don't know yet. Since i won't probably have time to do this work before ~2/3 weeks, i will temporary mark this bug "LATER". I've browsed slimserver CVS a bit more, and it appears that they really often do slight changes to the Perl modules they uses. So I think that mixing this with the vanilla CPAN modules from Portage would really be a hell to maintain. Thus, i will submit a new ebuild that drop all deps on Perl modules (but Time-HiRes, cause it needs to be compiled and was unmodified), and use their tree instead. That means that you Perl devs are no more involved, sorry for having bothered you. Created attachment 46428 [details]
media-sound/slimserver/slimserver-5.4.0.ebuild
Here is the modified ebuild without the additional Perl deps. Other changes
since previous version that i remember of:
- the "slimserver" user is also added to the "users" group (cause that's more
convenient to allow it reading the music available on the machine)
- if USE="-encode", then transcoding (ogg->mp3, etc.) rules are dropped
(that's more convenient when installing on a slow box, because transcoding
rules were used by default despite the machine can't handle it well)
It has been tested several days on an x86 laptop and a small ppc NAS (a
kurobox).
Oh, and another change is that i've added an optional dependency on the Apple Rendezvous' mDNSResponder, because it happened that some people want to use that. I will submit the ebuild for that service on a separate bug and mark this one "depends on ...". Created attachment 46429 [details]
files/slimserver.initd
And finally here is a slightly modified initd script, that handles some file
access rights tests a bit better.
There seems to be a patch missing from files/; in particular, the Shoutcast_recent_dir patch. When I attempt to emerge this ebuild, I receive the following message:
>>> emerge (1 of 1) media-sound/slimserver-5.4.0 to /
>>> md5 src_uri ;-) SlimServer_v5.4.0.tar.gz
>>> Unpacking source...
>>> Unpacking SlimServer_v5.4.0.tar.gz to /var/tmp/portage/slimserver-5.4.0/work * Applying slimserver-5.4.0--playlistdir_option.patch ... [ ok ]
* Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is:
*
* /usr/local/portage/media-sound/slimserver/files/slimserver-5.4.0--Shoutcast_recent_dir.patch
The init script does not create the PID file properly. When I re-emerge slimserver, an `/etc/init.d/slimserver start` brings output as expected (I enabled the debug lines in the files) AND the PID is written into /var/run/slimserver.pid. Nevertheless, when I grep `ps aux | grep slim`, I do not see the process. When I start manually `/usr/share/slimserver/slimserver --daemon` and e.g. `echo "12408" >> /var/run/slimserver.pid` the PID into /var/run/slimserver.pid, I can `/etc/init.d/slimserver stop` the server. When I use the initscript alone, I can not `/etc/init.d/slimserver stop` the server because 1.) a PID is put into /var/run/slimserver.pid, but the server dies (?) and `/etc/init.d/slimserver stop` finds no process to stop. BUT a repeated `/etc/init.d/slimserver start` says "WARNING: "slimserver" has already been started." as if start-stop-deamon had his own process list(?). At the moment, I can `emerge slimserver -v` but have to start the server directly with `/usr/share/slimserver/slimserver --daemon` to use it. Created attachment 47062 [details, diff] files/slimserver-5.4.0--Shoutcast_recent_dir.patch comment #20: oops, sorry, this is the missing file. comment #21: > the PID is written into /var/run/slimserver.pid. Nevertheless, when I grep > `ps aux | grep slim`, I do not see the process. That probably means that the server dies right after being launched, no? Could you turn on debugging messages and attach the last lines of your slimserver.log file please? Also copy/paste what is the command lined used by the init.d script. Thanks. is there a status update about this ebuild? It'd be great to have a maintained slimserver ebuild Created attachment 51744 [details]
media-sound/slimserver/slimserver-5.4.0.ebuild
A minor update that drops the mdns dependency and USE flag. The mdnsresponder
version in portage doesn't fit slimserver requirements, and adding a different
one that does would be bloat and conflicting with the existing mdnsd service.
Anyway, that's not really a loss of functionality: it simply means that user
will have to manually add the slimserver service to his Rendez-Vous server
configuration (howl or mDNSResponder).
The only blocking issue I see is what cprior has reported, if confirmed. But i've not been able to reproduce this behavior, and without more info, i really can't help. *** Bug 53524 has been marked as a duplicate of this bug. *** Created attachment 54408 [details]
Ebuild for v6.0b3.
I've added this ebuild based on the 5.4 one here to install SlimServer v6.0b3
as I'm about to get myself a SqueezeBox2. This way I can test that the software
functions as intended.
From this ebuild I've installed Slimserver on my Gentoo server, then d/l
SoftSqueeze from Slimserver (don't use 1.0 from sourceforge, it is incompatible
with this server!) and am now enjoying my MP3 collection via Wi-Fi.
Let me know if there is anything I can do to help getting this ebuild into
Portage, I'd even volunteer as maintainer (or co-maintainer) for it as I'll be
heavily reliant on it myself!
Thanks for filing the bug. This gave me some needed info to get slimserver running. I really wish it was in portage though. > I really wish it was in portage though.
I think it can wait for 6.0 now :)
Actually, i've seen this new version was out only a few days ago. I've started working on the ebuild, but there is still some work to do, so it will be ready... later.
v6.0b3 does not work. I will create an ebuild for 6.0.2 when I have the time. I have updated the ebuild for v6.0.2 and it seems to work OK with minor changes that seemed appropriate. Not sure how to attach it to this comment, so please contact me if you are interested. Basically, I think that the v6.0b3 ebuild should not delete the Bin directory as this is required for rebuilding the perl binaries. The 'path' information should also not be removed from the slimserver.pl file. However perhaps its not very 'gentoo' to download the required perl sources separately (this is my first ebuild modification) Hi;
Does anybody have an ebuild, a working /etc/init.d/slimserver startup
script, and a default /etc/conf.d/slimserver configuration file that works with
6.0.2? If they do could they please post it up here? (or e-mail me) I've been
fiddling around with various files downloaded from this list, mainly hacking the
6.0b3 stuff, but I haven't got it working yet.
I'm getting errors like "DBD::SQLite::db tables failed: file is encrypted
or is not a database(26) at dbdimp.c line 263 at
/usr/share/slimserver/Slim/DataStores/DBI/DataModel.pm line 126" when I try and
start it so I'm thinking it's still having perl problems.
Chris
The latest versions (certainly from 6.0.2) come with a script called
"build-perl-modules.pl" in there it lists the required packages as
Compress-Zlib-1.33.tar.gz
DBI-1.46.tar.gz
DBD-SQLite-1.08.tar.gz
HTML-Parser-3.45.tar.gz
Template-Toolkit-2.13.tar.gz
Time-HiRes-1.66.tar.gz
XML-Parser-2.34.tar.gz
All of which seem to be in portage at this time.
HTH.
Created attachment 65839 [details]
ebuild for slimserver version 6.1.1
Created attachment 65841 [details]
Configuration file used with slimserver 6.1.1
Created attachment 65842 [details]
init file to go with slimserver 6.1.1
I have used the information and the files available in this bug report and succeeded in making a usable ebuild, start/stop script and configuration file for version 6.1.1. I'll try to attach these files to this comment (otherwhise I will mail them to TGL). Essentially: - I changed a few pathnames to match my configuration (not important) - I use the official PERL packages and included the necessary dependencies - corrected a few errors (wrong package name, reference to non-existing file) - make /var/run/slimserver.pid reference hard-coded - moved --priority to slimserver options (instead of start-stop-daemon) options - removed user, group parameters because they were giving me errors I could not resolve (slimserver scripts had problems finding modules) I left my comments in the files, giving details about what I did. I hope this is of some use (it is the first time I play around with ebuilds Created attachment 66443 [details]
slimserver-ebuilds-6.1.1.tar.gz (New set of ebuilds for slimserver)
This is an almost completely revised set of ebuilds, config files, and init
scripts for the slimserver. Here are the most notable changes:
- Removes the CPAN directory completely, replaced by depending on the
correct perl module ebuilds. I had to create several new perl module
ebuilds for this, which are also included in this tarball.
- Fixed run-as-user support; now runs as ${SLIM_USER}:${SLIM_GROUP}
- Hard coded config files, cache directory, and log directory, and
placed them all in various subdirs for slimserver, so we can give
the slimserver user/group access to that folder and prevent permissions
problems that people had before.
- Tried to move things around to be more FHS compliant; install to
/opt/slimserver by default, since that seems best. Default folders to
/srv/music/* since the data will change, and that seemed like the best
solution according to FHS.
- Save environment variable configuration between emerges; it gets saved
strategically in /etc/conf.d/slimserver, so the ebuild (once installed)
will automagically pick up any changes the user made in there.
- Added a new system for automatically generating the convert.conf file based
on various things. User-defined convert.conf lines go in, as expected,
/etc/slimserver/convert.conf. The generated file is named
/etc/slimserver/conversions. To add filetypes for automatic generation,
/etc/slimserver/formats must be edited, and should be self-documenting.
- Cleaned up the /etc/init.d/slimserver file to make it work better, and now
it seems a lot saner. It previously checked for all kinds of exceptions
that could be made. Since the ebuild works by default now, that's not
necessary and the init script is now much smaller and easier to understand.
- Various other changes, I'm sure.
- Keep the /etc/slimserver/slimserver.conf between emerges, so we shouldn't
destroy any information, hopefully.
- Changed init script such that directory moves MUST be recorded in
/etc/conf.d/slimserver, thus forcing the ebuild to pick them up next time
around as well.
There are probably a lot more changes, but this works for me, and I think
it's now ready for wider-spread testing. The only part I haven't tested yet
is the USE-flag-dependent requirements for some of the perl modules... it might
be that the SlimServer software needs those modules no matter what. Please
test.
Created attachment 66447 [details]
slimserver-ebuilds-6.1.1.tar.gz (Fixed LICENSEs in perl ebuilds)
Went through and paid closer attention to the LICENSE field in the ebuilds; two
of the ones for perl have no stated license, so I defaulted to the Artistic
license, as I think that's what most perl modules specify when one isn't
listed.
Someone who knows more about that needs to verify that this is correct. No
other changes were made in this version.
Created attachment 66448 [details]
slimserver-ebuilds-6.1.1.tar.gz (Fixed a few brown-bag bugs)
Fixed a few brown-bag bugs:
- slimserver-formats-update didn't run without arguments, which it doesn't
need 99% of the time.
- Fixed init script to actually replace configuration directives in
/etc/slimserver/slimserver.conf like I said it would, but then forgot
to implement it.
- Modified init scripts to make sure the server user/group owns
/etc/slimserver/slimserver.conf so it can write back to it without any
problems.
Hopefully there aren't any more silly mistakes in this set of ebuilds.
Feedback is welcome.
I tride the slimserver tarball and when I want to start the server I get the following error: Can't locate Date/Parse.pm in @INC (@INC contains: /opt/slimserver/Plugins /opt/slimserver /opt/slimserver/CPAN /opt/slimserver/CPAN/arch/5.8.6/i686-linux-thread-multi /opt/slimserver/CPAN/arch/5.8.6/i686-linux-thread-multi/auto /opt/slimserver/CPAN/arch/5.8/i686-linux-thread-multi /opt/slimserver/CPAN/arch/5.8/i686-linux-thread-multi/auto /opt/slimserver/CPAN/arch/i686-linux-thread-multi /etc/perl /usr/lib/perl5/site_perl/5.8.6/i686-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.6/i686-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.5/i686-linux-thread-multi /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i686-linux-thread-multi /usr/lib/perl5/5.8.6 /usr/local/lib/site_perl .) at /opt/slimserver/Slim/Web/Pages.pm line 12. BEGIN failed--compilation aborted at /opt/slimserver/Slim/Web/Pages.pm line 12. Compilation failed in require at /opt/slimserver/Slim/Web/History.pm line 12. BEGIN failed--compilation aborted at /opt/slimserver/Slim/Web/History.pm line 12. Compilation failed in require at /opt/slimserver/Slim/Web/HTTP.pm line 35. BEGIN failed--compilation aborted at /opt/slimserver/Slim/Web/HTTP.pm line 35. Compilation failed in require at /opt/slimserver/Slim/Control/CLI.pm line 19. BEGIN failed--compilation aborted at /opt/slimserver/Slim/Control/CLI.pm line 19. Compilation failed in require at ./slimserver.pl line 221. BEGIN failed--compilation aborted at ./slimserver.pl line 221. I think there is a perl module missing in the dependencies. Created attachment 66555 [details]
slimserver-ebuilds-6.1.1.tar.gz (Fixed missing dependencies, other cleanups)
As per the previous comment, there were some missing perl dependencies that I
didn't catch in my first round of grepping the SlimServer source for the
packages it used. Changes:
- Fixed missing dependencies on perl packages
- Included new perl packages for some of those dependencies
- dev-perl/B-LexInfo
- dev-perl/B-Size
- dev-perl/Devel-Size
- dev-perl/Devel-Size-Report
- Moved some configuration files out of /etc/slimserver
- Everything in /etc/slimserver is now user-editable
- All configs now end with ".conf"
- Fixed ebuild to keep ALL settings from /etc/conf.d/slimserver
when re-emerging
Thanks for the feedback.
OK now it works. To make testing easier, here the following to set in /etc/portage/packages.kewords: media-sound/slimserver ~x86 dev-perl/Tie-Cache-LRU-Expires ~x86 dev-perl/Audio-FLAC-Header ~x86 dev-perl/Audio-Musepack ~x86 dev-perl/Audio-WMA ~x86 dev-perl/File-BOM ~x86 dev-perl/Ogg-Vorbis-Header-PurePerl ~x86 dev-perl/QuickTime-Movie ~x86 dev-perl/SQL-Abstract ~x86 dev-perl/SQL-Abstract-Limit ~x86 dev-perl/Tie-Cache-LRU ~x86 dev-perl/Tie-RegexpHash ~x86 dev-perl/enum ~x86 dev-perl/B-Size ~x86 dev-perl/B-LexInfo ~x86 dev-perl/Devel-Size-Report ~x86 dev-perl/Devel-Size ~x86 dev-perl/Array-RefElem ~x86 What changed that we have now a dependency of about 60 perl packages? >
> What changed that we have now a dependency of about 60 perl packages?
>
The SlimServer package from Slim Devices comes with a *lot* of CPAN modules in a
subdirectory named CPAN. Instead, I configured the ebuild to remove that
directory completely (rm -rf CPAN) and DEPEND-ed on the modules that the
SlimServer package needs. The SlimServer code itself didn't need everything in
the CPAN directory; it only needed some of them, but Slim Devices had to include
all of the dependencies for the modules it uses, such that their packages were a
drop-in solution on all platforms. That is not exactly the Gentoo way of doing
things, so I changed it:
The package now depends on each perl module individually, and has included
ebuilds for the perl modules not yet in portage. This way, the perl modules
become available to the system and can be updated independently of SlimServer
itself, thus incorporating bug fixes sooner... hopefully. However, this mass of
ebuilds should probably be split up into a single bug report for each, since all
of these perl modules need to go into portage before the slimserver ebuild can.
There are a couple items that probably need to be dealt with before this ebuild
is included in portage:
- Right now, we DEPEND on media-video/ffmpeg, which is a huge package
and may not be to some people's liking. I like it for the consistent
behavior across file formats (and its upcoming support for Apple Lossless
files), however I may be alone in that respect. Thus the next item:
- Consider USE='ffmpeg' and having a different formats.conf file for each
case (with ffmpeg and without ffmpeg), but that complicates DEPEND a
little. If we have ffmpeg, then only depend on ffmpeg, but otherwise,
we need to depend on a native *nix decoder for each supported format.
- Should carefully evaluate whether or not /opt/slimserver is the best place
to install this by default.
- Consider modifying slimserver-formats-update to also dynamically update
strings.txt (translated format descriptions) and types.conf (for MIME
types). This would allow one to use formats.conf to fully integrate
new formats to the SlimServer software.
- What platforms should we ~arch these ebuilds on by default? I'm on
amd64, so I assume ~x86 and ~amd64 are good, but I've seen ~ppc and
another. Perhaps KEYWORDS="~x86 ~amd64 ~ppc" for now? Is anyone on ppc
to test this?
That's where we stand for now. I need some help deciding how to proceed with
this. I think going for USE='ffmpeg' is probably a good idea, but I'd like to
hear some opinions first.
I find USE variables always something good to choose. But what else of encoder do you want to use instead off ffmpeg? I also supose ffmpeg is only used for peoble that use special fomats. A user with an mp3 collection won't need ffmpeg with slimserver. Am I right? A find /opt/slimserver a good location for the installation. What I don't really like is that the slimserver related perl modules are installed in /usr/lib/perl5 directore. But these modules are only used by slimserver. Right? I would prefer to put them also into /opt/slimserver. Is it not more difficult to maintain the package if you have 10s of packages to maintain instead only of one? My 2 cents. I am not a dev so maybe they have an other opinion. Created attachment 66955 [details]
slimserver-ebuilds-6.1.1.tar.gz (Made ffmpeg optional, various cleanups)
Alright, so here's the last round of changes in the ebuild, as best I can
summarize them:
- Added USE='ffmpeg' support. Disable WMA support without it, because I
don't
know of any other WMA decoder for Linux.
- Added support for using individual decoders in the formats.conf files, like
oggdec, mppdec, flac, and shorten. This is really the second half to
supporting USE='ffmpeg' instead of requiring ffmpeg all the time.
- Changed the ebuild to only try to add the new user/group slimserver in
pkg_setup(), so that we don't go through trying to randomly add the
user and group as set in /etc/conf.d/slimserver, as that's a bad behavior.
- Hardcoded /opt/slimserver in place of SLIM_INSTALL_DIR; users shouldn't
ever really need to change this.
- Don't chown -R /opt/slimserver to SLIM_USER and SLIM_GROUP. This should
mostly remove the ebuild's dependency on the chosen user/group for the
server daemon. The server shouldn't ever need to write back to its own
code, so this shouldn't break anything.
- Still chown the data directories to SLIM_USER and SLIM_GROUP, as this is
*probably* what the user wants, and will already have them set as such,
so this should make the ebuild as unobtrusive as possible for upgrading
an existing install. If someone disagrees, tell me.
- Fixed formats.conf to default to some more sane values. For example,
nobody will ever want to decode an MP3 to WAV and then stream as WAV to a
hardware player capable of decoding the MP3 itself. That's just silly.
The new formats.conf fixes that problem.
- To catch changes to convert.conf, the SlimServer must be restared. So
there's no sense in making the user run slimserver-formats-update
separately; I embedded that code into the init script such that it
will automagically update convert.conf if the user has changed either
/etc/slimserver/convert.conf or /etc/slimserver/formats.conf since the
last regeneration.
- Removed a lot of old comments from the ebuild; general cleanups. Renamed
to slimserver-6.1.1-r1.ebuild since this has undergone so many changes.
Makes lives easier for those of us who are testing it now...
I think this is slowly becoming release-worthy material. I think this is as
simple as this ebuild will get, as far as I can tell. Further comments are
welcome. I'm not a Gentoo developer, so we *really* need some developer input
here before we can start getting this set of ebuilds approved to go into
portage.
-- Paul Marks
Please, attach plaintext files for review, we don't want tarballs. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3#doc_chap2 Also, mark all obsolete attachments as such for easier orientations. Reopen once you've done so. Thanks. Created attachment 67023 [details]
slimserver-6.1.1-r1.ebuild
As per developer comment, I have split the ebuilds up into individual bugs,
booted the tarball, and am uploading the individual files here. Sorry about
the mistake with the tarball. I guess I had a bad case of RTFM.
Created attachment 67024 [details]
files/convert.conf
Created attachment 67025 [details]
files/formats.conf-ffmpeg
Created attachment 67026 [details]
files/formats.conf-other
Created attachment 67027 [details]
files/slimserver.conf
Created attachment 67028 [details]
files/slimserver.initd
Created attachment 67029 [details]
files/slimserver.confd
I can't mark this bug as REOPENED since I don't have permissions. Can someone REOPEN this or give me the privileges needed to do so? Again, sorry about the tarballs; hopefully this is better. Thanks for your help. -- Paul Marks (In reply to comment #56) > I can't mark this bug as REOPENED since I don't have permissions. Can someone > REOPEN this or give me the privileges needed to do so? Sure, reopened. It is much easier to review things if you can open them directly in browser instead of having to download and unpack tarballs. Thanks. The provided init script doesn't work for me. linux ~ # /etc/init.d/slimserver start * Starting service slimserver [ !! ] * Service slimserver started OK linux ~ # ps aux | grep slim root 29449 0.0 0.0 2600 520 pts/2 R+ 21:58 0:00 grep slim No logs file is created, and neither is the pid file. If I run the start-stop-daemon command from the init script in a shell the server starts just fine. Any ideas? In the "for whatever it's worth category, I would suggest that the choice of /opt for install directory should be reconsidered. Folk following the Gentoo install guides will not have a /opt partition, meaning that /opt will be in the root partition. Following Gentoo standard pratice, the root partition is normally very small--software packages are not expected to install there. Suggest that you pick some place in the /usr hierarchy, which is where folk on Gentoo systems expect software to install. Denny The ebuild worked OK for me. It might be more gentoo like to create dependencies to all the CPAN perl modules, but seeing that many are not in portage yet, it does make installation more time consuming. I have only tried playing mp3's so far - work's OK. I get the following error in the /var/log/slimserver.log file Use of uninitialized value in subroutine entry at /usr/lib/perl5/vendor_perl/5.8.5/DBIx/ContextualFetch.pm line 51. I have no idea if this is due to the ebuild or to some other problem with my gentoo setup (or slimserver itself) Thanks for the hard work Paul. -- Rob Foweraker To Nathan:
Are you using the more recent baselayout scripts? I mean any of the
sys-apps/baselayout-1.12.* versions. I run a server and I had encoutnered
several strange problems regarding how start-stop-daemon works. For example,
using 1.12.* also broke courier-authlib for me (and possibly courier, as
well---I can't remember).
Anyway, so I've developed this ebuild and init script on
baselayout-1.11.13-r1. If you're using one of hte 1.12.* versions, I might
suggest trying the latest from 1.11.* and seeing if this makes your problem go
away. Until 1.12.* goes stable officially, I'm not sure that it's worth trying
to troubleshoot this init script on that. If you're still on 1.11.*, though,
I'll look into it once I can get some more information.
---
To Danny:
Actually, several packages, go in /opt. /opt is for binary-only packages,
but this is in the same style. You'll note that Java JREs and JDKs go in /opt,
as does OpenOffice.org, and I think parts, if not all, of Thunderbird and
Firefox go in there as well. This is because those programs would litter /usr
with their own settings and files that are not strictly binaries, documentation,
or shared libraries.
The fact that SlimServer includes a smattering of its own perl modules that
*do* *not* belong in /usr/lib/perl5 makes it seem like a good candidate for
including its binaries, configuration files, and code within a /opt directory.
If you browse around /opt/slimserver, I think you'll see why it's not a good
idea to try to cram all of that stuff into /usr, since no other programs could
make use of those files and code.
Please note: I'm not a developer, so one of them should really weigh in on
the use of /opt vs. something else; /opt is just the best decision I was able to
make on my own after looking at some of the other things that end up in /opt.
---
To Rob:
First, thanks! I agree that it sucks having these packages split across all
of these bugs is a rotten way to get early adopters to test the ebuild. I'd
posted a few overlay tarballs that had everything one would need, but that was a
Bad Thing regardin the Gentoo Developer Handbook, so I split it up and filed
these bugs the proper way. However, for simplicities sake, I will start hosting
tarballs of all the necessary ebuilds and a quick HOWTO so people can get
started without some of the hassle.
Second, that error message looks like it's because one of those perl modules
runs with "use strict;" and perl is just a little more verbose about complaining
about using uninitialized values. It's not a bug nor an error, just a warning
that should be redirected to whoever is maintaining DBIx::ContextualFetch.
Don't worry, it's not a problem with your system or the ebuilds. =)
---
I'll post a link to the slimserver HOWTO and ebuilds sometime Very Soon Now
once I get them available on the web. Thanks for your feedback, everyone!
Alright, per a few people's request (and I'm sure some who haven't made mention
of it), I'm posting this mass of ebuilds in an overlay tarball at the following
location:
http://files.ged.dynodns.net/slimserver/
The HOWTO should help you get started. Please recognize that I'm on a cable
modem so bandwidth is certainly nothing to write home about. Anyhow, that's
about it for now. Enjoy!
(In reply to comment #61) > To Nathan: > > Are you using the more recent baselayout scripts? I mean any of the > sys-apps/baselayout-1.12.* versions. I run a server and I had encoutnered > several strange problems regarding how start-stop-daemon works. For example, > using 1.12.* also broke courier-authlib for me (and possibly courier, as > well---I can't remember). Yes I am. > Anyway, so I've developed this ebuild and init script on > baselayout-1.11.13-r1. If you're using one of hte 1.12.* versions, I might > suggest trying the latest from 1.11.* and seeing if this makes your problem go > away. Until 1.12.* goes stable officially, I'm not sure that it's worth trying > to troubleshoot this init script on that. Downgraded to 1.11.13. Works fine now. Nathan: I can't test baselayout-1.12.* on my system, as it breaks courier, and I use that heavily for mail. However, I have uploaded a set of changed files on my website, as mentioned earlier, as -r2-testing. If you would like to give that a spin on the new baselayout and tell me if it works or not, that'd be great. I think the problem may have been that when slimserver daemonized, it changed its name, which might have been throwing start-stop-daemon off since it's now being stricter about such things. Anyhow, here's the link if you'd like to try it: http://files.ged.dynodns.net/slimserver/slimserver-6.1.1-r2-testing.tar.gz Paul, Sun's binary products (JRE/JDK/OpenOffice) do install into /opt. However this is essentially a choice made by Sun at compile time, and is somewhat to be expected as /opt is the standard place to install 3rd party packages in SVR4/Solaris. The standard Firefox and Thunderbird builds go into /usr. There are binary only ebuilds of Firefox/Thunderbird that do go into /opt. [I am at a loss to explain why these binary only ebuilds even exist :-] So anyway... I took a look around, and there are more than a hundred packages that install into /opt. I must say, I was surprised! Shocked even :-) However, this is a small minority of the ebuilds (there are over 10,000 packages for Gentoo). They also are focused on installation of packages for proprietary binary packages (vendors that do not release source code). I tend to view SlimServer as a source code distribution than a binary one. Anyway, I want thank you for your work. I will test the ebuild tarball tomorrow. Denny Paul: It works! linux portage # /etc/init.d/slimserver start * Starting service slimserver * Service slimserver started OK linux portage # ps aux | grep slim 109 26961 6.6 5.2 87844 53760 ? SNs 22:23 0:00 /usr/bin/perl -w /opt/slimserver/slimserver.pl --daemon [snip] Paul, I tested the ebuild using the r2-testing version, and it worked great. I'm using baselayout 1.12.0_pre8-r2. Denny Created attachment 68486 [details]
files/slimserver.conf
Updates default configuration file to include SLIM_ITUNES_XML, so that all
paths are specified in /etc/conf.d/slimserver and not through the web
interface.
Created attachment 68487 [details]
files/slimserver.initd
Update the init script to force the XML library path from SLIM_ITUNES_XML, so
that the web interface is no longer needed for that.
Created attachment 68488 [details]
files/slimserver.confd
Update to include a description and default value for the SLIM_ITUNES_XML
setting.
Created attachment 68489 [details, diff]
files/slimserver-6.1.1.patch
This patch is applied to the whole slimserver directory, and here's a short
list of what it does:
- Disables the web interface for settings that come from
/etc/conf.d/slimserver
- Fixes an issue with severe ambiguity in strings.txt related to ignoring
the "checked" attribute of songs from an iTunes library. Unfortunately, I
only changed the English translations. Others are more than welcome to
fix other languages if they're ambiguous as well.
- Patches slimserver.pl such that it doesn't rename itself to just
"slimserver" when it daemonizes, thus resolving the problems that were
being seen with the stricter start-stop-daemon from baselayout-1.12.x.
That's it for this patch, but it's a great step in the direction of cleaning
things up to make this integrate much better with Gentoo.
Created attachment 68490 [details] slimserver-6.1.1-r3.ebuild Update the ebuild to move /etc/slimserver/slimserver.conf to do a few new things, as mentioned with the patch above: - Apply slimserver-6.1.1.patch when installing to correct those issues - Handle SLIM_ITUNES_XML with a default value, like the other variables, so that it gets neatly passed through to be as non-destructive as possible. - Update references to /etc/slimserver/slimserver.conf and move the location to /var/cache/slimserver/slimserver.conf, as that's a more appropriate place for it, since it changes at run-time, and the user should never need to modify that file by hand anymore, now that there's a clear distinction between what's in the web interface and what's in /etc/conf.d/slimserver. Alright, that's it for tonight's smattering of updates. The new set of ebuilds is available here: http://files.ged.dynodns.net/slimserver/slimserver-6.1.1-r3.tar.gz Cheers! (In reply to comment #72) Tested r3, worked fine. Good idea to move slimserver.conf, btw. Denny I noticed that the SlimScrobbler plugin only works if the package Net-DNS is installed. This was part of the original CPAN lib but does not seem to be in the ebuild. Would it be possible to add this dependancy to the ebuild? I know its not strictly required for slimserver but it makes life easier when installing this particular plugin and saves someone having to spend time finding out why their plugin won't work. Cheers Rob Well, I understand why you'd like to add dev-perl/Net-DNS as a dependency for this package, but the reason it's not there is that the SlimServer code itself has no dependency on the Net::DNS perl module. You can grep through the entirety of the SlimServer code for Net::DNS and Net/DNS, and you won't find anything. If there were an ebuild for SlimScrobbler, then that's where the dependency would belong. For now, though, since the slimserver package doesn't depend on it directly, I can't really justify adding it as a dependency... I don't know why Net::DNS would be included in the original CPAN folder if it's not needed by SlimServer itself, but that's their call, not mine. If you really really want Net::DNS in here, I'm open to hearing better reasons. It's just that adding a dependency in one package to support a separate add-on module doesn't seem like the right thing to do... Thanks for finding the dependency though; at the very least it would be useful if someone decides to create a SlimScrobbler package later. Cheers, - Paul There are two good reasons I can think of 1. Adding the package means that the final slimserver is closer to the standard release, which does include this package - perhaps they did that for a reason. 2. If someone else wants to install this plugin they don't waste any time trying to work out why it doesn't work in the gentoo install but does in every other install. However, perhaps if some of the more popular plugins could be emerged as well, then this would be a better solution. Is it feasible to emerge the plugins? At least there is a trace of the problem in this bug thread now. Rob What would be the best strategy for installing plugins? There seem to be two sorts of plugins 1. ones that just require a single file to be added into the plugins directory. It seems like overkill to me to have ebuilds for these. 2. ones like AlienBBC which require mplayer and realplayer to be installed. It might be nice to have ebuilds for these. As SlimScrobbler requires an extra package, it also falls into this category. Rob I stuffed the ebuild.tar.gz in /usr/local/portage and emerge slimserver -vp till
I caught all Perl dependencies and added them to /etc/portage/package.keywords .
Still, upon emerge slimserver it won't start:
renaissance ~ # /etc/init.d/slimserver start
* Starting SlimServer ...
Use of uninitialized value in join or string at /usr/lib/perl5/5.8.6/File/Spec/U
nix.pm line 73.
Use of uninitialized value in join or string at /usr/lib/perl5/5.8.6/File/Spec/U
nix.pm line 73.
Use of uninitialized value in join or string at /usr/lib/perl5/5.8.6/File/Spec/U
nix.pm line 73.
Use of uninitialized value in join or string at /usr/lib/perl5/5.8.6/File/Spec/U
nix.pm line 73.
Use of uninitialized value in join or string at /usr/lib/perl5/5.8.6/File/Spec/U
nix.pm line 73.
Use of uninitialized value in join or string at /usr/lib/perl5/5.8.6/File/Spec/U
nix.pm line 73.
Use of uninitialized value in require at (eval 4) line 2.
Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.6/i686-l
inux/Time/HiRes.pm line 7.
Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.
6/i686-linux/DynaLoader.pm line 181.
Use of uninitialized value in require at (eval 6) line 2.
Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.6/i686-l
inux/DBD/SQLite.pm line 6.
Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.
6/i686-linux/DynaLoader.pm line 181.
Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.
6/i686-linux/DynaLoader.pm line 181.
Use of uninitialized value in require at (eval 8) line 2.Use of uninitialized
value in require at /usr/lib/perl5/vendor_perl/5.8.5/i686-linux/XML/Parser.pm
line 14.Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.
5/i686-linux/XML/Parser/Expat.pm line 499.Use of uninitialized value in join or
string at /usr/lib/perl5/5.8.6/File/Spec/Unix.pm line 73. Use of uninitialized
value in concatenation (.) or string at /usr/lib/perl5/5.8.6/i686-linux/
DynaLoader.pm line 181.
Use of uninitialized value in require at (eval 9) line 2.
Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.6/i686-
linux/HTML/Parser.pm line 14.Use of uninitialized value in concatenation (.) or
string at /usr/lib/perl5/5.8.6/i686-linux/DynaLoader.pm line 181.
Use of uninitialized value in require at (eval 10) line 2.
Use of uninitialized value in require at /opt/slimserver/slimserver.pl line 192.
Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.6/XML/
Simple.pm line 1538.
Use of uninitialized value in require at /opt/slimserver/slimserver.pl line 203.
Use of uninitialized value in require at /opt/slimserver/slimserver.pl line 203.
Can't locate Slim/Utils/Misc.pm in @INC (@INC contains: /CPAN /CPAN/arch/5.8.6/
i686-linux /CPAN/arch/5.8.6/i686-linux/auto /CPAN/arch/5.8/i686-linux /CPAN/
arch/5.8/i686-linux/auto /CPAN/arch/i686-linux /etc/perl /usr/lib/perl5/
site_perl/5.8.6/i686-linux /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/
site_perl /usr/lib/perl5/vendor_perl/5.8.6/i686-linux /usr/lib/perl5/
vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.
8.5/i686-linux /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i686-linux /usr/
lib/perl5/5.8.6 /usr/local/lib/site_perl .) at /opt/slimserver/slimserver.pl
line 203.
BEGIN failed--compilation aborted at /opt/slimserver/slimserver.pl line 203.Use
of uninitialized value in require at /usr/lib/perl5/5.8.6/AutoLoader.pm line 92
during global destruction.Use of uninitialized value in require at /usr/lib/
perl5/5.8.6/AutoLoader.pm line 92 during global destruction.
[ !! ]
I use [ebuild R ] sys-apps/baselayout-1.11.13-r1 -bootstrap -build -static
-unicode 0 kB if that is of importance.
In the past, I only used the slimserver ebuild that was in here last March 2005,
but that too I could never get to work with initscripts (on another machine,
other install though).
I even *cough* rebooted after the install so all Perl-paths (if sth. like that
exists) should have been updated.
I have been testing the r3 ebuild with different file formats and I find that I cannot play WAV files and therefore also have problems playing Apple lossless and anything else that is streamed to the player in WAV format. I have a windows machine as well and the same WAV files play fine when using that to run slimserver. I have looked at the code a bit and can't find any reason why this might be but I suspect that there is a missing dependency or perhaps a version that has been patched for the slimserver distribution. The Squeezebox2 player displays the message 'Could not open file'. My server is an ~x86. Here is an extract from the log file... 2005-09-24 22:19:28.7228 f2:3d:ef:4f:30:3e: Switching to mode play from stop 2005-09-24 22:19:28.7240 openSong on: file:///svr/music/itunes/iTunes%20Music/Test/Test/2-20%20Test.wav 2005-09-24 22:19:28.7264 Got /svr/music/itunes/iTunes%20Music/Test/Test/2-20%20Test.wav from file url file:///svr/music/itunes/iTunes%20Music/Test/Test/2-20%20Test.wav 2005-09-24 22:19:28.7272 extracted: /svr/music/itunes/iTunes Music/Test/Test/2-20 Test.wav from file:///svr/music/itunes/iTunes%20Music/Test/Test/2-20%20Test.wav Use of uninitialized value in concatenation (.) or string at /opt/slimserver/Slim/Player/Source.pm line 1360. 2005-09-24 22:19:28.7318 openSong: getting duration 171.026, size , endian and offset 0 for file:///svr/music/itunes/iTunes%20Music/Test/Test/2-20%20Test.wav 2005-09-24 22:19:28.7321 openSong: not bothering opening file with zero size or duration 2005-09-24 22:19:28.7324 Error opening current track, so mark it as already played 2005-09-24 22:19:28.7343 writeNoBlock: writing a segment of length: 8 2005-09-24 22:19:28.7350 writeNoBlock: writing a segment of length: 1290 2005-09-24 22:19:28.7355 Couldn't open song. Stopping. Has anyone else got the same problem? Rob To cprior:
I don't know if this is the issue, but you're running perl 5.8.6. Most of
those warnings are coming from system perl modules, nothing inside SlimServer.
However, the fact that it can't find Slim/Utils/Misc.pm is why it's dying. I'm
using perl 5.8.7 and this is not causing me any trouble. I noticed that
/opt/slimserver is not in your @INC, but it's probably not in mine.
Resolution: I think I'm going to bump this to requiring
>=dev-lang/perl-5.8.7, since that's the only thing I can think of that might be
causing your issues right now. It's still ~x86 and ~amd64, though. SlimServer
makes heavy use of FindBin.pm and other perl modules which are part of the main
perl package, so that might fix it. If not, let me know.
To Rob:
The problems you're seeing I actually ran in to at one point. There is a
logic problem in the upstream code, where it will not play a song if it can't
read the duration and size (read: if they are undefined, versus being 0). If
you are trying to play WAV or ALAC from files listed in your iTunes library, it
should pick this up without a problem, but if you try to play the file directly,
it will croak. This seems to hold true for WAV files as well, though I don't
know why it's not reading the file size.
Anyway, I've updated my patch to include a fix for this, and I'll have some
new ebuilds available in a few minutes.
Everyone:
Sorry for taking so long (relatively) to respond. Hopefully these fixes
(including the dependency bump) will fix the problems we've seen. As always,
the updated ebuild(s) and HOWTO are at:
http://files.ged.dynodns.net/slimserver/
Created attachment 69183 [details]
files/slimserver.initd
Updated for:
- Don't try to manage the enable/disable iTunes setting automagically, as it
didn't work, and I can't disable it in the web config, so just let the user
decide whether they want it on/off in the web interface, but specify folder
locations in /etc/conf.d/slimserver
- Update the formats config if /etc/conf.d/slimserver changes, since the
user might have changed either SLIM_INPUT_FORMATS or SLIM_OUTPUT_FORMATS,
which is cause for regenerating the convert.conf seen by SlimServer.
Created attachment 69184 [details, diff]
files/slimserver-6.1.1.patch
Updated patch includes the following fixes:
- Fix an upstream logic bug that causes SlimServer to not play files for
which it can't find both the duration and the size (undef), versus only
choosing to not play a song if it knows the duration or size to be 0.
Created attachment 69185 [details]
slimserver-6.1.1-r5.ebuild
Updated the ebuild:
- Bumped perl dependency to >=dev-perl/perl-5.8.7, in case some of the
seen bugs were due to 5.8.6. If this doesn't fix those problems,
I'll revert the ebuild to 5.8.1.
- Made sure that versioning schemes between the ebuilds here and the
tarballs I host match. For some reason they'd been 1 version off,
I believe. At least they were on my system. Now everything is at
-r5.
I think that there is a typo in the function configure_default_formats in the slimserver-6.1.1-r5.ebuild - there is a 'use fmpeg' instead of use 'ffmpeg' at line 179 Also, just a small point which - it might be best to keep the Bin directory and just remove the contents - this is where the mplayer.sh script is placed for the AlienBBC plugin - however anyone using Gentoo will probably know the mkdir command... Rob Re: slimserver-6.1.1-r5.ebuild There seems to be a dependency problem, here is the output from me emerge. I have a new clean system with few little perl additions. # emerge --ask --verbose slimserver These are the packages that I would merge, in order: Calculating dependencies - emerge: there are no ebuilds to satisfy "dev-perl/Tie-Cache-LRU". To Graig See comment #44 Many of the perl package dependencies are either masked or not actually in portage, therefore you will need to install the portage overlay (see comment #62) or download each ebuild not in portage (see other gentoo bugs listed in the section Bug 73832 depends on: at the top of the page) and install them manually. Rob Just as a note, I had to manually emerge the following module to get SlimServer to start, minor dependency needing added there I think :) dev-perl/MP3-Info -- * Starting SlimServer ... Can't locate MP3/Info.pm in @INC (@INC contains: /opt/slimserver /opt/slimserver/CPAN /opt/slimserver/CPAN/arch/5.8.7/i686-linux /opt/slimserver/CPAN/arch/5.8.7/i686-linux/auto /opt/slimserver/CPAN/arch/5.8/i686-linux /opt/slimserver/CPAN/arch/5.8/i686-linux/auto /opt/slimserver/CPAN/arch/i686-linux /etc/perl /usr/lib/perl5/site_perl/5.8.7/i686-linux /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.7/i686-linux /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.5/i686-linux /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.6/i686-linux /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.7/i686-linux /usr/lib/perl5/5.8.7 /usr/local/lib/site_perl .) at /opt/slimserver/Slim/Music/Info.pm line 16. BEGIN failed--compilation aborted at /opt/slimserver/Slim/Music/Info.pm line 16. Compilation failed in require at /opt/slimserver/Slim/Utils/Misc.pm line 22. BEGIN failed--compilation aborted at /opt/slimserver/Slim/Utils/Misc.pm line 22. Compilation failed in require at /opt/slimserver/slimserver.pl line 203. [ !! ]iled--compilation aborted at /opt/slimserver/slimserver.pl line 203. -- slimserver 6.2 is out. These ebuilds are pretty hairy, so hopefully someone is interested in bumping it? That said, the 6.1.1-r5 tar is working quite well for me, but i'd definitely appreciate better unicode and wma support, among a lot of other features I am having the same problem as cprior in comment 78, but I am using perl 5.8.7. Full text of starting follows. However if I cd to /opt/slimserver before starting the it works fine, ie cd /opt/slimserver && /etc/init.d/slimserver start -->works cd /any/place/else && /etc/init.d/slimserver start --> produces the following error nick@sf ~ $ sudo /etc/init.d/slimserver restart * Stopping SlimServer ... [ ok ] * Starting SlimServer ... Use of uninitialized value in join or string at /usr/lib/perl5/5.8.7/File/Spec/Unix.pm line 73. Use of uninitialized value in join or string at /usr/lib/perl5/5.8.7/File/Spec/Unix.pm line 73. Use of uninitialized value in join or string at /usr/lib/perl5/5.8.7/File/Spec/Unix.pm line 73. Use of uninitialized value in join or string at /usr/lib/perl5/5.8.7/File/Spec/Unix.pm line 73. Use of uninitialized value in join or string at /usr/lib/perl5/5.8.7/File/Spec/Unix.pm line 73. Use of uninitialized value in join or string at /usr/lib/perl5/5.8.7/File/Spec/Unix.pm line 73. Use of uninitialized value in require at (eval 5) line 2. Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/Time/HiRes.pm line 7. Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.7/i686-linux/DynaLoader.pm line 181. Use of uninitialized value in require at (eval 7) line 2. Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/DBD/SQLite.pm line 6. Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.7/i686-linux/DynaLoader.pm line 181. Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.7/i686-linux/DynaLoader.pm line 181. Use of uninitialized value in require at (eval 9) line 2. Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/XML/Parser.pm line 14. Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/XML/Parser/Expat.pm line 499. Use of uninitialized value in join or string at /usr/lib/perl5/5.8.7/File/Spec/Unix.pm line 73. Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.7/i686-linux/DynaLoader.pm line 181. Use of uninitialized value in require at (eval 10) line 2. Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.7/i686-linux/HTML/Parser.pm line 14. Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/5.8.7/i686-linux/DynaLoader.pm line 181. Use of uninitialized value in require at (eval 11) line 2. Use of uninitialized value in require at /opt/slimserver/slimserver.pl line 192. Use of uninitialized value in require at /usr/lib/perl5/vendor_perl/5.8.7/XML/Simple.pm line 1538. Use of uninitialized value in require at /opt/slimserver/slimserver.pl line 203. Use of uninitialized value in require at /opt/slimserver/slimserver.pl line 203. Can't locate Slim/Utils/Misc.pm in @INC (@INC contains: /CPAN /CPAN/arch/5.8.7/i686-linux /CPAN/arch/5.8.7/i686-linux/auto /CPAN/arch/5.8/i686-linux /CPAN/arch/5.8/i686-linux/auto /CPAN/arch/i686-linux /etc/perl /usr/lib/perl5/site_perl/5.8.7/i686-linux /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.7/i686-linux /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.7/i686-linux /usr/lib/perl5/5.8.7 /usr/local/lib/site_perl .) at /opt/slimserver/slimserver.pl line 203. BEGIN failed--compilation aborted at /opt/slimserver/slimserver.pl line 203. Use of uninitialized value in require at /usr/lib/perl5/5.8.7/AutoLoader.pm line 92 during global destruction. Use of uninitialized value in require at /usr/lib/perl5/5.8.7/AutoLoader.pm line 92 during global destruction. [ !! ] /etc/init.d/slimserver listformats doesn't work.
nick@sf /opt/slimserver $ sudo /etc/init.d/slimserver listformats
* The following formats are recognized by the SlimServer:
nick@sf /opt/slimserver $
However if I run the commands taken from the script it works:
nick@sf /opt/slimserver $ cat /etc/slimserver/formats.conf | grep -v
'^[[:space:]]*\(#.*\)\?$' | sed -e 's#[[:space:]]*:[[:space:]]* #:#g' | sed -e
's#\([^:]*\):\([^:]*\):.*#\t\1 - \2#g'
# thats an amlagamation of lines 21 and 191 of the initscript
aif - AIFF
wav - WAV
flc - FLAC
fec - FLAC with Cuesheet
mp3 - MP3
mov - Quicktime
mpc - Musepack
shn - Shorten
ogg - Ogg/Vorbis
wma - Windows Media
nick@sf /opt/slimserver $
I'm using slimserver-6.1.1-r5 and things seem to mostly work. Thanks for the ebuild! I did have one problem with playlists. I made a few playlists and I noticed that they weren't saved in the /srv/music/playlists/ directory. I checked the log file and found this: 2005-10-29 11:12:29.8356 Could not open /srv/music/playlists/Test.m3u for writing. I checked the directories and everything in /srv is owned by root. I changed the owner and group of the playlists directory to slimserver and now everything works. Should any of the other directories be owned by slimserver? Also, there are a huge number of perl warnings in the slimserver log file such as the following: Use of uninitialized value in subroutine entry at /usr/lib/perl5/vendor_perl/5.8.6/DBIx/ContextualFetch.pm line 51. Can these be safely ignored? added CC Created attachment 71769 [details]
files/slimserver.initd
Updates to the init script:
- Updated to agree with move from /opt/slimserver to /usr/lib/slimserver
- Fixes problems related to not starting from /usr/lib/slimserver by
changing to /usr/lib/slimserver before launching the server. This should
eradicate errors seen earlier when it was started from a directory other
than the one in which SlimServer was installed.
- Fixes problem related to /etc/init.d/slimserver listformats not generating
any output. I forgot to run checkconfig which sets $FORMATSDB.
Created attachment 71770 [details, diff]
files/slimserver-6.2.0.patch
Hey guys look! We've got a new version! Changes:
- Updated patch to work with SlimServer 6.2.0.
- Upstream fixed some of the confusing bits of strings.txt, so I removed
my English-only changes from that file in favor of the better (and
translated) fixes made upstream.
Created attachment 71771 [details] slimserver-6.2.0.ebuild Updated to upstream 6.2.0, with the following changes: - Moved installation to /usr/lib/slimserver, as I heard it's preferable to /opt/slimserver from a few developers. - Added a bit to make sure the directories are owned by SLIM_USER and SLIM_GROUP only if they don't exist already. This shouldn't break any existing installations. The only directory that *needs* to be writable by SLIM_USER/SLIM_GROUP is the playlists folder (SLIM_PLAYLISTS_DIR). For whoever saw a problem with playlists, you'll need to manually change ownership of those directories; apologies for the bum ebuilds regarding that. - New version no longer uses dev-perl/QuickTime-Movie, and instead uses dev-perl/MP4-Info. Updated dependencies to correct this. For whoever mentioned dependency problems earlier: check your USE flags. Likely the required modules were not DEPENDed on because you didn't have the mp3 USE flag enabled (or whatever it was). In the Gentoo style, this ebuild doesn't require any ebuilds it doesn't need, so check your USE flags and see if that fixes your errors. Past that, we have a shiny new 6.2 tree. The ebuild tarball is available, as always, at: http://files.ged.dynodns.net/slimserver/ See upstream for significant changes from 6.1 -> 6.2. Enjoy! I just emerged 6.2 and get the following error when trying to start slimserver: # /etc/init.d/slimserver start * Starting SlimServer ... Can't locate Audio/WMA.pm in @INC (@INC contains: /usr/lib/slimserver/Plugins /usr/lib/slimserver /usr/lib/slimserver/CPAN /usr/lib/slimserver/CPAN/arch/5.8.7/i686-linux /usr/lib/slimserver/CPAN/arch/5.8.7/i686-linux/auto /usr/lib/slimserver/CPAN/arch/5.8/i686-linux /usr/lib/slimserver/CPAN/arch/5.8/i686-linux/auto /usr/lib/slimserver/CPAN/arch/i686-linux /etc/perl /usr/lib/perl5/site_perl/5.8.7/i686-linux /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.7/i686-linux /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.5/i686-linux /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.6/i686-linux /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.7/i686-linux /usr/lib/perl5/5.8.7 /usr/local/lib/site_perl .) at /usr/lib/slimserver/Slim/Player/Protocols/MMS.pm line 14. BEGIN failed--compilation aborted at /usr/lib/slimserver/Slim/Player/Protocols/MMS.pm line 14. Compilation failed in require at /usr/lib/slimserver/Slim/Player/Source.pm line 38. BEGIN failed--compilation aborted at /usr/lib/slimserver/Slim/Player/Source.pm line 38. Compilation failed in require at /usr/lib/slimserver/Slim/Player/Playlist.pm line 13. BEGIN failed--compilation aborted at /usr/lib/slimserver/Slim/Player/Playlist.pm line 13. Compilation failed in require at /usr/lib/slimserver/Slim/Buttons/AlarmClock.pm line 16. BEGIN failed--compilation aborted at /usr/lib/slimserver/Slim/Buttons/AlarmClock.pm line 16. Compilation failed in require at /usr/lib/slimserver/Slim/Buttons/Settings.pm line 12. BEGIN failed--compilation aborted at /usr/lib/slimserver/Slim/Buttons/Settings.pm line 12. Compilation failed in require at /usr/lib/slimserver/Slim/Display/Display.pm line 14. BEGIN failed--compilation aborted at /usr/lib/slimserver/Slim/Display/Display.pm line 14. Compilation failed in require at /usr/lib/slimserver/slimserver.pl line 204. BEGIN failed--compilation aborted at /usr/lib/slimserver/slimserver.pl l [ !! # $ locate WMA.pm /usr/lib/slimserver/Slim/Formats/WMA.pm I'm guessing that the references to Audio/WMA.pm need to be changed to Formats/WMA.pm ? Your problem is that the dev-perl/Audio-WMA package is not installed. The most likely cause of this is that you are trying to use WMA files somewhere without having set USE='wma' for slimserver, which will cause the ebuild to not depend on dev-perl/Audio-WMA. From what I could gather when digging around in the SlimServer source code, format modules are only loaded if it needs to gather information about those kinds of files. I don't know exactly when it decides to load these modules--it could be if it sees WMA in convert.conf (in which case, having WMA in SLIM_INPUT_FORMATS or SLIM_OUTPUT_FORMATS will cause this error), or it could be that it only loads them when trying to scan a WMA file (in which case you'd be fine until it tries to scan a WMA file). My current guess is the former, because it's failing at startup. Anyway, if you don't have USE='wma' for slimserver, then enable that, and try again. This package will break if you try to use an audio format for which you didn't enable the appropriate USE flags, and I suspect this is what you're seeing. I really need to document this better somewhere else. If you DO have USE='wma', however, and it's still broken for you, then let me know. For now, it's working for me... Good luck! - Paul I tracked the problem down to the unmerged Audio-WMA and Audio-Muspack. I
emerged these and it still didn't work.
I got your response (thanks for the quick reply!) and checked make.conf for wma.
I'm currently not using that flag. Then I checked my music collection and
failed to find any wma files. There may be a bug with slimserver if wma is not
set. If slimserver can't fail gracefully when wma is not set then it may be
better to just require the WMA modules.
So I set wma in make.conf and remerged slimserver (with --deep and --newuse
options) and I get the following error:
# /etc/init.d/slimserver start
* Starting SlimServer ...
Can't locate object method "add_suspects" via package "Encode::Guess" at
/usr/lib/slimserver/Slim/Utils/Unicode.pm line 92.
INIT failed--call queue aborted.
I checked the problem line and found:
# Setup suspects for Encode::Guess based on the locale - we might also
# want to use our own Language pref?
if ($locale ne 'utf8') {
Encode::Guess->add_suspects($locale);
}
I commented out the Encode line and now slimserver starts up. I briefly tested
it by playing a song and it seems to work.
What version of perl are you running? Encode::Guess is included in my perl distribution (5.8.7). I can't figure out when it was added to the base perl installation, but it looks like I need to bump the DEPEND atom for perl so that your problem doesn't show up anymore. Yeah, looks like these audio format modules are required regardless of whether or not they're used, so I'll just make them hard DEPENDs, even though it brings in a few packages we don't need otherwise... It looks like Encode::Guess is being loaded (from what I can tell), but add_suspects isn't a valid function. Let me know what version of perl you have, and I'll see if I can figure out what on earth is going on. The problem is that I have my locale set to UTF-8, so it's not a problem for me. Check "man Encode::Guess" to see information about your version of Encode::Guess, and let me know if add_suspects is missing. Once I get some more info, I'll post the ebuilds that should finally work for most everyone... I'm using perl 5.8.7 but gentoo still seems to have others installed:
$ cd /usr/lib/perl5/
$ ls
5.8.5 5.8.6 5.8.7 site_perl vendor_perl
$ find -type d -name 'Encode'
./5.8.7/Encode
./5.8.7/i686-linux/auto/Encode
./5.8.7/i686-linux/Encode
$ find -name '*.pm' | wc -l
1265
$ grep add_suspects $(find -name '*.pm')
./5.8.7/i686-linux/Encode/Guess.pm: $self->add_suspects(@_);
./5.8.7/i686-linux/Encode/Guess.pm:sub add_suspects{
./5.8.7/i686-linux/Encode/Guess.pm:=item Encode::Guess->add_suspects
./5.8.7/i686-linux/Encode/Guess.pm:Or you can use C<add_suspects> method. The
difference is that
./5.8.7/i686-linux/Encode/Guess.pm:C<add_suspects> adds.
./5.8.7/i686-linux/Encode/Guess.pm: Encode::Guess->add_suspects(qw/euc-jp
shiftjis 7bit-jis/);
./5.8.7/i686-linux/Encode/Guess.pm: Encode::Guess->add_suspects(qw/euc-kr
euc-cn big5-eten/);
I'm not sure what any of this means. From the earlier error messages, the perl
5.8.7 files seem to be included before the 5.8.6 files.
Looks like an upstream bug to me! There's no "use" or "require" for Encode::Guess in Slim/Utils/Unicode.pm, which is a major oopsie for someone upstream. I've bundled what should be a fix for this in the monolithic patch we've got. Hopefully this will make your system happy again. New files incoming! Created attachment 71826 [details]
files/slimserver.conf
The configuration file format changed in this release, and I missed it the
first time around. Updating our files to match. Changes:
- Moved config file to new YAML (?) config format
Created attachment 71827 [details]
files/slimserver.initd
Adjusting for the new config file format. Changes:
- Adjusted sed statements (for SLIM_???_DIR variables, etc) to match the new
format.
Created attachment 71828 [details, diff]
files/slimserver-6.2.0.patch
Seems that someone found yet another upstream bug. Changes:
- Added 'require Encode::Guess' to Slim/Utils/Unicode.pm as it seemed to be
conspicuously absent. Hopefully this fixed the bug seen earlier.
Created attachment 71829 [details]
slimserver-6.2.0-r1.ebuild
Update the ebuild. Notable changes:
- Hopefully fixed this DEPEND madness once and for all. It seems that
all these perl modules for obtaining format info are required, whether
the format is actually in use or not. Made them mandatory deps instead
of USE-dependent deps.
And that's all, folks!
I upgraded to 6.2.0-r1 slimserver fails to start with the following log message: --- !perl/YAML::Error code: YAML_PARSE_ERR_TEXT_AFTER_INDICATOR msg: No text allowed after indicator line: 262 document: 1 ... at /usr/lib/slimserver/Slim/Utils/Prefs.pm line 972 Yeah, I had that here but then it miraculously disappeared after a minute. I don't know whose bug it is, it might be an upstream migration problem. Anyway, it says "line 262," so go to line 262 of /var/cache/slimserver/slimserver.conf. See what's on that line, and post what's there. If it's not one of the parameters set in /etc/init.d/slimserver (look for the sed command around line 125), then you can probably just delete the offending line, and try starting it again. Paste the offending line here, though, just so we can get an idea of what's going on... I assume you were using 6.1.1 before moving to 6.2.0? Thanks! Yeah, I was using 6.1.1 before 6.2.0 Here is an extract from /var/cache/slimserver/slimserver.conf . . . tcpWriteMaximum: 20 thumbSize: 100 timeFormat: |%I:%M:%S %p titleFormat: - TITLE - DISC-TRACKNUM. TITLE - TRACKNUM. TITLE - TRACKNUM. ARTIST - TITLE - TRACKNUM. TITLE (ARTIST) - TRACKNUM. TITLE - ARTIST - ALBUM - FILE.EXT - TRACKNUM. TITLE from ALBUM by ARTIST - TITLE (ARTIST) - ARTIST - TITLE titleFormatWeb: 1 udpChunkSize: 1400 . . . line 262 is the timeformat line with the strange pipe character. I removed the pipe and added single quotes around the argument. Slimserver seems to be running now. Thanks! It would be great if the log entry mentioned the name of the file that it was failing to parse. Removing the dev-perl/QuickTime-Movie depend, since 6.2.0 doesn't need it, as far as I can tell. Can someone (a developer?) with the necessary permissions either change the summary to reflect the version bump or give me the permissions necessary to make changes on the same level as the owner/submitter (or perhaps change me to the owner)? I think the current owner seems to have abandoned this, and I've pretty much taken over... There are some other changes I'd like to make regarding attachments and such, and it'd just be easier in the future if I didn't have to ask for someone else to do it... Thanks! Hi, I've just upgraded from 6.1.1-r5 to 6.2.0-r1, and am having problems with starting/stopping the server. When starting (# /etc/init.d/slimserver start), it seems to start fine: * Starting SlimServer... [ ok ] However, I try to log into the web config, and I get a connection refused error. If I check to see if slimserver is running (# ps -aux), slimserver isn't listed there. Also, if I check in /var/run/slimserver to see if a pidfile is there, there isn't one. However, if I try to start the server again (# /etc/init.d/slimserver start), I get: * WARNING: "slimserver" has already been started. If I try to then stop the server, I get: * Stopping SlimServer... [ !! ] What seems to be the problem here? If you're sure slimserver isn't running you can try: # /etc/init.d/slimserver zap I have to do this whenever there is a perl compilation error. Deleting the pid file may have the same effect. Ever since I received my slimserver I have been unable to play ogg files. The details of it can be found here: http://forums.slimdevices.com/showthread.php?p=62516#post62516 Here is a quick summary as it relates to the gentoo ebuild: 1) I had very little response from the forums so I sent an email to slimdevices tech support. The first thing they asked about was what all my configuration files are. After I sent the files tech support responded with "these are completely non-standard, we're not even using ffmpeg anymore, install the stock slimserver tarball first and see if you can repro the problem." Do the ebuild config files need to be different than the standard ones? It would certainly be easier to track down problems if we matched the stock slimserver installation as closely as possible. 2) Instead of installing the stock tarball I just tried to get the ebuild config files to look more like the standard ones. With the following changes I was able to get ogg working: a) Added the follwing to /etc/slimserver/convert.conf ogg mp3 * * [sox] -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s $-x$ - | [lame] --resample 44100 --silent -q $QUALITY$ --abr $BITRATE$ -r - - ogg aif * * [sox] -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s $-x$ - ogg flc * * [sox] -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s $-x$ - | [flac] -cs --compression-level-0 --totally-silent --endian big --channel 2 --bps 16 --sample-rate 44100 --sign signed - b) gentoo's sox is pretty out of date. Even the ~x86 build is v12.17.7 which is a month and a half old. versions less than 12.17.8 have a bug with the -x switch which causes the above commands to play static. This is fixed in 12.17.18. I downloaded the sox tarball and installed the resulting binary in /usr/local/bin. There is an outstanding gentoo bug that deals with this: http://bugs.gentoo.org/show_bug.cgi?id=99830 c) slimserver seems to prefer the sox in /usr/bin instead of the new one in /usr/local/bin. I'm not sure why it is doing this since my path has /usr/local/bin first. As a temporary workaround I renamed /usr/bin/sox to something else. Perhaps slimserver should either honor the path or look for binaries in /usr/local/bin first? 3) Are other people able to play ogg files with the standard ebuild? If so, I'd be willing to try to track down the problem I'm having with ffmpeg. I'm running stock gentoo with a few things marked ~x86 (such as perl). (In reply to comment #111) > If you're sure slimserver isn't running you can try: > > # /etc/init.d/slimserver zap > > I have to do this whenever there is a perl compilation error. Deleting the pid > file may have the same effect. Thanks, but I'm unsure how this helps me. There's still no pid file being created, so there's no pid file to zap. What might be wrong for it not to create a pid file? Hi all I have been playing around with this on sparc, after editing a some the ebuild, I have a working version of 6.2.0-r1 (so can ~sparc be added to all ebuild?). But it not quite work perfectly, the main problem I have had is with the slimserver config file /var/cache/slimserver/slimserver.conf 1) Currently the config file generated by the init script is wrong and causes the slimserver to fail to load, I have tracked this down to timeFormat: |%I:%M:%S %p. which should be entered as timeFormat: '|%I:%M:%S %p'. The slimserver also resets this part of the config each time the server is restarted. Currently I have been unable to find the cause of this problem. 2) After the initial install another part of the config was also entered incorrectly audiodir: '' "audiodir: '/data/mp3'": ~ was added to the config file, which caused the server to not find any of the music. By changing this to audiodir: /data/mp3 "audiodir: '/data/mp3'": ~ has fixed the problem, this change to the config does not change after each reboot 3) Lastly I have to ask why the main config file is in /var/cache/slimserver and not /etc/slimserver/ ? In addition to this I have also started testing getting this version to work with mysql, is there any possibility to have mysql added to the use flags? Currently I have emerged both Msql-Mysql-modules and Class-DBI-mysql, and the server is talking to the mysql data (haveing changed the config file), but this cause the following error 2005-11-04 23:01:14.5225 Backtrace: frame 0: Slim::DataStores::DBI::DBIStore::newTrack (/usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm line 526) frame 1: Slim::DataStores::DBI::DBIStore::updateOrCreate (/usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm line 177) frame 2: Slim::DataStores::DBI::DBIStore::objectForUrl (/usr/lib/slimserver/Slim/Utils/Scan.pm line 543) frame 3: Slim::Utils::Scan::readList (/usr/lib/slimserver/Slim/Utils/Scan.pm line 215) frame 4: Slim::Utils::Scan::addToList_run (/usr/lib/slimserver/Slim/Utils/Scan.pm line 155) frame 5: Slim::Utils::Scan::addToList (/usr/lib/slimserver/Slim/Music/MusicFolderScan.pm line 63) frame 6: Slim::Music::MusicFolderScan::startScan (/usr/lib/slimserver/Slim/Music/Import.pm line 49) frame 7: Slim::Music::Import::startScan (/usr/lib/slimserver/slimserver.pl line 1050) frame 8: main::checkDataSource (/usr/lib/slimserver/slimserver.pl line 537) frame 9: main::init (/usr/lib/slimserver/slimserver.pl line 563) frame 10: main::main (/usr/lib/slimserver/slimserver.pl line 1222) 2005-11-04 23:01:14.5235 Couldn't create track for file:///data/mp3/Armin_van_Buuren_-_Live_at_Amnesia_Ibiza_(3FM)_24-08-2004 -4CHOON : Can't insert new Slim::DataStores::DBI::Track: Can't get last insert id at /usr/lib/slimserver/Slim/DataStores/DBI/ DBIStore.pm line 426 at /usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm line 426 I will start to have a look what might be causing this error. SittingLittleDuck (In reply to comment #114) > 1) Currently the config file generated by the init script is wrong and causes > the slimserver to fail to load, I have tracked this down to timeFormat: > |%I:%M:%S %p. which should be entered as timeFormat: '|%I:%M:%S %p'. The > slimserver also resets this part of the config each time the server is > restarted. Currently I have been unable to find the cause of this problem. Oo Ooh! That fixed my problem... with me as well, it reverts with each restart of slimserver. I guess that might be why it worked perfectly on first run, and then after that it failed each time. Thanks! I've started running softsqueeze to play music on the same computer that hosts slimserver. Since softqueeze is a java app the command line for launching it gets a little hairy. I wrote this small bash shell to make it easier to launch: softsqueeze BEGIN #!/bin/bash which java &> /dev/null if [ $? == 0 ]; then java -jar /usr/lib/slimserver/HTML/EN/html/softsqueeze/SoftSqueeze.jar else echo java not found in path fi softsqueeze END I'm not sure it's useful to anyone else but if so then the slimserver ebuild could install it in /usr/bin/ Having played around a bit more I'm getting a little closer to tracking down a the bug over the timeformat. I would appear that the problems is coming from Slim/Utils/Prefs.pm, as this is the file that sets timeFormat for to |%I:%M:%S %p via the line 'timeFormat' => q(|%I:%M:%S %p), now the q() function should add the quotes ' ' around it, but for some reason the quotes are missing when it gets written to the config file. |%I:%M:%S %p apears to be the default case, which applies when the variable has not been set else where, which would explain why it was changing on startup. Having changed the value for the timeFormat via the web interface, it has now correctly added the '' around the value for timeformat in the prefs files, and does not rewirte it on startup. I will have a further look to see if I can find the actual cause of this one. My problems with mysql apear to have been sloved by upgrading to version 5 of mysql, but while I emerged that it also updated one the perl modules, so it could have been that which fixed the problem. I'm getting the same issue with the timeformat in the current ebuild (6.2.0-r1)
I have also see a strange issue. I emerged and when I did a full scan for new
music slimserver quit! This seemed to be while scanning a set of mpc files
(muse). From the log:
Can't locate object method "titlesort" via package "So far so good" (perhaps
you forgot to load "So far so good"?) at
/usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm line 1653 (#1)
Uncaught exception from user code:
Can't locate object method "titlesort" via package "So far so good"
(perhaps you forgot to load "So far so good"?) at
/usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm line 1653.
at /usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm line 1652
Slim::DataStores::DBI::DBIStore::_postCheckAttributes('Slim::DataStores::DBI::DBIStore=HASH(0x9a04804)',
'Slim::DataStores::DBI::Track=HASH(0x9ff32b4)', 'HASH(0x9ff3368)', 0) called at
/usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm line 520
Slim::DataStores::DBI::DBIStore::updateOrCreate('Slim::DataStores::DBI::DBIStore=HASH(0x9a04804)',
'HASH(0x9f825f4)') called at
/usr/lib/slimserver/Slim/Formats/Parse.pm line 100
Slim::Formats::Parse::_updateMetaData('file:///srv/music/playlists/Bryan%20Adams/Bryan%20Adams%20-%2...',
'Bryan Adams - Summer
of \'69') called at /usr/lib/slimserver/Slim/Formats/Parse.pm line 161
Slim::Formats::Parse::readM3U('FileHandle=GLOB(0x9fa431c)',
'file:///srv/music/playlists/Bryan%20Adams/Bryan%20Adams%20-%2...',
'file:///srv/music/playlists/Bryan%20Adams/Bryan%20Adams%20-%2...') called at
/usr/lib/slimserver/Slim/Formats/Parse.pm line 58
Slim::Formats::Parse::parseList('file:///srv/music/playlists/Bryan%20Adams/Bryan%20Adams%20-%2...',
'FileHandle=GLOB(0x9fa431c)',
'file:///srv/music/playlists/Bryan%20Adams/Bryan%20Adams%20-%2...') called at
/usr/lib/slimserver/Slim/Utils/Scan.pm line 654
Slim::Utils::Scan::readList('file:///srv/music/playlists/Bryan%20Adams/Bryan%20Adams%20-%2...',
'ARRAY(0x9f9c6b8)') called at /usr/lib/slimserver/Slim/Utils/Scan.pm line 215
Slim::Utils::Scan::addToList_run('ARRAY(0x9203d68)') called at
/usr/lib/slimserver/Slim/Utils/Scheduler.pm line 99
Slim::Utils::Scheduler::run_tasks() called at
/usr/lib/slimserver/slimserver.pl line 618
main::idle() called at /usr/lib/slimserver/slimserver.pl line 570
main::main() called at /usr/lib/slimserver/slimserver.pl line 1222
Slim::DataStores::DBI::Track Slim::DataStores::DBI::Track=HASH(0x9ff32b4)
destroyed without saving changes to bitrate, secs, age, remote, ct, size, audio,
titlesort, album, tracknum, titlesearch, tag, title, fs, year at
/usr/lib/slimserver/Slim/DataStores/DBI/DBIStore.pm
line 914
My 'emerge info':
Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2,
2.6.13-gentoo-r3 i686)
=================================================================
System uname: 2.6.13-gentoo-r3 i686 Pentium III (Coppermine)
Gentoo Base System version 1.6.13
dev-lang/python: 2.3.5-r2
sys-apps/sandbox: 1.2.12
sys-devel/autoconf: 2.13, 2.59-r6
sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils: 2.15.92.0.2-r10
sys-devel/libtool: 1.5.18-r1
virtual/os-headers: 2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=pentium3 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/share/config /var/bind /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=pentium3 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/overlays/slimserver"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 aac acl acpi apache2 apm atm avi berkdb bitmap-fonts crypt cups curl
eds emboss encode ffmpeg flac foomaticdb fortran gdbm gif gpm gstreamer imlib
ipv6 jpeg libclamav libg++ libwww mad mikmod mmx motif mp3 mpeg musepack ncurses
nls oav ogg oggvorbis pam pdflib perl png python quicktime readline redline
samba sdl shorten spell ssl tcpd tiff truetype truetype-fonts type1-fonts vorbis
wma xml2 xv zlib userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS
Still working on the timeFormat issue and getting the ebuild to use mysql, and then they made a new version of slimserver 6.2.1, so I have created an ebuild for the new version. First you need to add a couple of new perl modules, Path-Class and Encode ebuilds for these can be found at http://www.sittinglittleduck.com/slimserver-ebuild/Path-Class.tar.bz2 http://www.sittinglittleduck.com/slimserver-ebuild/Encode.tar.bz2 Just untar them into /usr/local/portage/dev-perl/ I guess that as these are new ebuild I need to create bug entry for each one? But I'm not sure, so can someone direct me on this? ebuild for the slimserver can be found at http://www.sittinglittleduck.com/slimserver-ebuild/slimserver-6.2.1.ebuild Just place that file in /usr/local/portage/media-sound/slimserver/ You will also most likely have to run "ebuild slimserver-6.2.1.ebuild digest" As with all new things I had to make a couple changes to the slimserver it's self to get it to work. When I get round to it I will make a patch for the changes, but until then you will have to edit the files by hand. in /usr/lib/slimserver/Slim/Utils/Unicode.pm Add "use Encode::Guess;" by the other use commands. in /usr/lib/slimserver/Slim/DataStores/DBI/DataModel.pm Comment out the line Class::DBI->use_object_index(0); For some reason slimserver could not find the use_object_index() function, I could find virtually no information on this function, so I commented it out to see what would happen, and the problem went away. However doing this may have caused new problems to be introduced, but currently my player is running fine :) That Still working on the timeFormat issue and getting the ebuild to use mysql, and then they made a new version of slimserver 6.2.1, so I have created an ebuild for the new version. First you need to add a couple of new perl modules, Path-Class and Encode ebuilds for these can be found at http://www.sittinglittleduck.com/slimserver-ebuild/Path-Class.tar.bz2 http://www.sittinglittleduck.com/slimserver-ebuild/Encode.tar.bz2 Just untar them into /usr/local/portage/dev-perl/ I guess that as these are new ebuild I need to create bug entry for each one? But I'm not sure, so can someone direct me on this? ebuild for the slimserver can be found at http://www.sittinglittleduck.com/slimserver-ebuild/slimserver-6.2.1.ebuild Just place that file in /usr/local/portage/media-sound/slimserver/ You will also most likely have to run "ebuild slimserver-6.2.1.ebuild digest" As with all new things I had to make a couple changes to the slimserver it's self to get it to work. When I get round to it I will make a patch for the changes, but until then you will have to edit the files by hand. in /usr/lib/slimserver/Slim/Utils/Unicode.pm Add "use Encode::Guess;" by the other use commands. in /usr/lib/slimserver/Slim/DataStores/DBI/DataModel.pm Comment out the line Class::DBI->use_object_index(0); For some reason slimserver could not find the use_object_index() function, I could find virtually no information on this function, so I commented it out to see what would happen, and the problem went away. However doing this may have caused new problems to be introduced, but currently my player is running fine :) Thats your lot, hope you all enjoy the new version! Just out of interest what else needs to be done to get this added to the main portage tree?? SittingLittleDuck OK, sorry for dropping out for a little while, everyone. I'm currently working on a new ebuild for 6.2.1, along with a new monolithic patch to go alongside. The trace posted earlier about a crash while scanning the library is an upstream bug, not something we've done, to the very best of my knowledge. Also, I'm putting together a little script to make sure that I no longer miss any perl dependencies for this ebuild. I missed a couple in this release (dev-perl/GD, dev-perl/RPC-XML, and a couple we don't have: dev-perl/Path-Class, and dev-perl/JSON). I will be coming out with those in the near future. Just wanted to give everyone a status update; I'm trying to maintain this as best I can, but some weeks I just can't keep up. Be on the lookout for updates soon :-) This bug is getting ridiculously long. I've got a new tarball for 6.2.1, and
here are the notable changes:
- Moved to SlimServer 6.2.1
- Include workaround in the init script for the timeFormat issues seen
in the config file.
- Added "mysql" and "postgres" USE flags so that those who wish to use
a full-fledged RDBMS on the back end may do so. These flags DO NOT
configure anything for you, they merely cause slimserver to DEPEND on
dev-perl/DBD-mysql or dev-perl/DBD-Pg, respectively.
As always, the tarball is available from me:
http://files.ged.dynodns.net/slimserver/slimserver-6.2.1.tar.gz
Enjoy!
Created attachment 73156 [details]
files/slimserver.initd
Modified init script to go with 6.2.1, changes:
- Include workaround for timeFormat issue; hopefully this works for everyone.
Created attachment 73157 [details, diff]
files/slimserver-6.2.1.patch
Updated patch file to work with 6.2.1, changes:
- Added use_object_index problem. Gentoo has Class::DBI 3.x, whereas
SlimServer ships with 0.96. Best I could tell, this function was removed
a long time ago as it's not needed. Everything else should work fine as
far as I could tell.
Created attachment 73158 [details]
slimserver-6.2.1.ebuild
New ebulid for 6.2.1, notable changes:
- Added "mysql" and "postgres" to IUSE
- For each of mysql and postgres, depend on the appropriate DBD packages
for those who want an RDBMS on the back end. No configuration is done
by the ebuild, this just causes slimserver to depend on dev-perl/DBD-Pg
and/or dev-perl/DBD-mysql as appropriate.
I just tried to install 6.2.1 over 6.2.0 and got some dependency problems: # emerge -pv slimserver These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] dev-libs/mm-1.3.0 220 kB [ebuild N ] net-www/gentoo-webroot-default-0.2 -no-htdocs 64 kB [ebuild N ] net-www/apache-1.3.33-r12 -apache2 -doc -lingerd -no-suexec +pam (-selinux) +ssl -static-modules 3,239 kB [ebuild N ] www-apache/mod_perl-1.27-r4 363 kB [ebuild N ] dev-perl/RPC-XML-0.53 108 kB [ebuild N ] net-www/mod_ssl-2.8.24-r1 0 kB [ebuild N ] dev-perl/Path-Class-0.13 15 kB [1] [ebuild N ] media-libs/gd-2.0.32 +X -fontconfig +jpeg +png +truetype 573 kB [ebuild N ] dev-perl/GD-2.23 +X +gif +jpeg +png +truetype 246 kB [ebuild N ] dev-perl/JSON-1.00 18 kB [1] [ebuild U ] media-sound/slimserver-6.2.1 [6.2.0-r1] +aac +encode +ffmpeg +flac +mp3 -musepack -mysql -postgres -shorten +vorbis +wma 6,974 kB [1] Total size of downloads: 11,827 kB Portage overlays: [1] /usr/local/portage/overlays/slimserver [2] /usr/local/portage/overlays/misc It looks like there is a dependency problem : slimserver ==> RPC-XML ==> mod_perl ==> apache Slimserver should not require apache, right? Not much we can do about RPC-XML depending indirectly on apache; SlimServer uses it in some places, though it seemed to work OK without the module. However, since the dependency is there, we have to include it; if you disagree with the fact that we're indirectly depending on apache, you'll have to take that up with the RPC-XML guys and their DEPEND on mod_perl. It's not a problem we can deal with, other than removing the depend on RPC-XML and risk some breakage when someone tries to use that functionality. Two issues Found with tarball d/l from comment #121 ----- 1. On install found a missing dependency as per below, fixed by adding dependency manually and updating Manifest. >>> Source unpacked. Can't locate Module/Build.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/site_perl/5.8.6/i686-linux /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.6/i686-linux /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i686-linux /usr/lib/perl5/5.8.6 /usr/local/lib/site_perl .). BEGIN failed--compilation aborted. Can't locate Module/Build.pm in @INC (@INC contains: /etc/perl /usr/lib/perl5/site_perl/5.8.6/i686-linux /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.6/i686-linux /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.6/i686-linux /usr/lib/perl5/5.8.6 /usr/local/lib/site_perl .). BEGIN failed--compilation aborted. * Using Module::Build * * Please post a bug on http://bugs.gentoo.org assigned to * perl@gentoo.org - Path-Class-0.13 was added without a dependancy * on dev-perl/module-build * * --- 2. !!! Digest verification Failed: !!! /usr/local/portage/overlays/local/dev-perl/MP4-Info/MP4-Info-1.05.ebuild !!! Reason: Filesize does not match recorded size Fixed manually. Question - why is /etc/slimserver/convert.conf empty post install? Should there not be entries there, as the server plain ole doesn't work without them? Lemme know, ta! :) Johnny:
1. This snuck by me. The CPAN listing had a Makefile.PL, but I overlooked the
fact that it also had a Build.PL, indicative of needing
dev-perl/module-build.
2. Beats me. I've uploaded a new tarball, and I forcefully recalculated the
digest for MP4-Info, just in case.
3. If you read the comment in that file, it says /etc/slimserver/convert.conf
is for custom, user-defined formats. Formats that ship with this ebuild are
calculated using a better method; look in /etc/slimserver/formats.conf if
you're curious. These files are then processed and combined to make
/usr/lib/slimserver/convert.conf, which is what the software actually
reads. The setup in /etc/slimserver is less confusing than managing the
whole of convert.conf manually.
4. New tarball:
http://files.ged.dynodns.net/slimserver/slimserver-6.2.1-r0.tar.gz
Paul, regarding (3) are you able to play ogg files with your default install? I mentioned problems that I had with this back in comment #112 and never heard anything. Thanx for the ebuild. Great that you put so much effort in this. I found a small "oops" in on of the ebuild files in slimserver-6.2.1-r0.tar.gz. In the file "Devel-Size-Report-0.10.ebuild" there's a line stating a dependence on Scalar-List-Utils. The full package line should be " >=perl-core/Scalar-List-Utils-1.13"., not "dev-perl/Scalar-List-Utils-1.13" Hope this helps. 6.2.1 emerges fine for me here. good work. ogg is working in the default install. Currently this ebuild is installing a configuration file into /var/cache. This is a bad idea - FHS reserves /var/cache for files that can be safely deleted at any time by the administrator. http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA Somewhere in /etc looks good to me. I dont agree with the rationale for using /var/cache rather than /etc in comment #72..... > since it changes at run-time, and the user should never > need to modify that file by hand anymore .... the same is true of /etc/passwd, but we dont move that to /var/cache ;-) Squeezebox arrived in the post today.... but Ive been having problems :-( Tracked down, I believe, to the non-standard convert.conf installed by this ebuild. Problems include: a. It uses ffmpeg with the -hq switch. The ffmpeg changelog lists that this switch was removed in version 0.4.1. That causes the SB to stall with no audio output. Evidence is left in /var/log/slimserver/slimserver.log. b. After removing all the -hq switches from /etc/slimserver/formats.conf, oggs failed to play. /var/log/slimserver/slimserver.log indicates that ffmeg is being restarted repeatedly (however they do play via the mp3 stream to mplayer, hence my success report in comment #132) c. I tried replacing /etc/slimserver/formats.conf with the one installed by the ebuild if you are not using USE=ffmpeg. success! d. I tried replacing the /var/lib/slimserver/convert.conf with the one from the slimserver tarball. (need to delete the call to formats_update in /etc/init.d/slimserver to avoid it being overwritten). This seems to work better... For ogg decoding it is using sox rather than oggdec, which is giving much lower latency on starting playback; less than a second, compared to perhaps 3 seconds. I found the whole system of rewriting convert.conf dynamically based on various other configuration files moderately confusing. Not least because it is *different* to upstream, which invalidates most of the good documentation out there. There are several privilege escalation vulnerabilities in /etc/init.d/slimserver which allow the slimserver user to gain root. Various files owned by slimserver are edited or have their permissions changed by root, without care for races. An issue I found with the most recent tarballs (r0 & r1): Streaming WMA directly to the Squeezebox2 doesn't work (protocol mms:). You need to use the Audio::WMA Perl module supplied in the Slimserver tarball. Check http://forums.slimdevices.com/showthread.php?t=17978&highlight=audio%3A%3Awma for an explanation. Regards, ...urs Created attachment 77289 [details]
AlienBBC ebuild
Attached is an ebuild for AlienBBC, a popular plugin for slimserver supporting BBC (and other) radio streams.
> You need to use the Audio::WMA Perl module supplied in the Slimserver tarball.
This issue has been affecting me for the last month or so. Do we just grab the slimserver tarball, extract only that module and make/test/install it? Or is this module in CVS? (which is beyond my capababilities as a newbie)
I see from the linked thread that Slim uses a custom 0.8 while cpan is 0.7
Maybe an expert can create a new gentoo tarball which includes this module for mms:// capability?
Created attachment 77300 [details] ebuild for Audio-WMA version 0.8 from slimserver distribution Attached is ebuild for Audio-WMA-0.8 to fix WMA problem described in comment #136. This ebuild extracts the perl module from the slimserver distribution rather than from CPAN. To test this ebuild: a. use the overlay tarball linked above b. copy this into dev-perl/Audio-WMA in your overlay directory c. in that directory, run "ebuild Audio-WMA-0.8.ebuild digest" d. ACCEPT_KEYWORDS=\~x86 emerge --oneshot Audio-WMA Note to whoever bumps the slimserver ebuild next: include version 0.8 as a dependency. Alright, I've put together a new tarball with the following significant
changes:
- Use format-specific tools for decoding files regardless of whether ffmpeg
is in the USE flags. The only difference between the ffmpeg-enabled
and non-ffmpeg enabled builds is now the ability to decode Apple Lossless
and WMA. Only ffmpeg provides those capabilities.
- Changed to using an updated sox ebuild to decode Ogg files, as it is
purportedly faster according to an email I was sent. This should also
resolved the mixed results for Ogg as mentioned in comment #130.
- Fixed package atom for Scalar-List-Utils in Devel-Size-Report as per
comment #131.
- Comment #133 was a nice catch from the FHS that I missed completely.
SlimServer now stores its cache files in /var/cache/slimserver, but the
dynamically updated config files now live in /var/lib/slimserver.
This is similar to the fact that things like PostgreSQL store data files
in /var/lib/postgres, and such. I still don't believe that slimserver.conf
belongs in /etc/slimserver, because it is held constantly open by
SlimServer while running, and shouldn't be edited by a user in that state, as
any changes would be overwritten later. All settings the user should want to
change that can't be modified at runtime in the web are in the conf.d file.
Anything more is accessible through the web interface.
- Eliminated the -hq switch from ffmpeg, even though it's still in the man
page, as per comment #134.
- Updated ogg decoding to use sox instead of oggdec; also mentioned in
comment #134.
- I have eliminated SLIM_USER and SLIM_GROUP in favor of statically
referencing slimserver:slimserver in the interest of security, following
the concerns voiced in comment #135.
I'm not much of a security expert, but I've done my best to eliminate any
further security risks. Please review the new init script, and if you
happen to spot more issues, please post more specific details so I can
resolve them for sure.
- Updated the Audio-WMA ebuild to install 0.8 from the SlimServer package.
This should address everything mentioned in comment #136, comment #138, and
comment #139.
Also a note: please submit new ebuilds in the appropriate bugs. The bug
for Audio-WMA is bug #103943.
Whew, that sums it up. The new overlay tarball, as always, is available here:
http://files.ged.dynodns.net/slimserver/slimserver-6.2.1-r1.tar.gz
Slim keeps dieing on me when using the ExBrowse3 skin. This seems to be something wrong with JSON. Here's the output with d_plugin.
2006-01-17 00:01:06.8263 ERROR: _getFileContent: Couldn't open: html/images/mute.gif
2006-01-17 00:01:26.4725 JSON request: {"method":"slim.getPlayers","params":[]}
2006-01-17 00:01:26.4734 JSON response ready
2006-01-17 00:01:36.1638 JSON request: {"method":"slim.getPlayers","params":[]}
2006-01-17 00:01:36.1649 JSON response ready
2006-01-17 00:01:37.6455 JSON request: {"method":"slim.doCommand","params":["192.168.0.40",["status"]]}
2006-01-17 00:01:37.6505 JSON response ready
2006-01-17 00:01:37.7826 JSON request: {"method":"slim.getPlaylist","params":["192.168.0.40",0,100]}
Invalid value at /usr/lib/perl5/vendor_perl/5.8.7/JSON/Converter.pm line 149.
2006-01-17 00:01:38.4373 Shutting down plugins...
Comment on attachment 77300 [details]
ebuild for Audio-WMA version 0.8 from slimserver distribution
Removing my ebuild - made obsolete by the one from Pauls tarball.
Comment on attachment 77289 [details] AlienBBC ebuild AlienBBC ebuild now in bug 119891 Ive reviewed the tarball at http://files.ged.dynodns.net/slimserver/slimserver-6.2.1-r1.tar.gz. Several comments/questions....... 1. I believe all security problems have been fixed - nice work. 2. The big sed script in init.d/slimserver patches the timeFormat line. What is the rationale for that? nothing seems to break for me if I remove it. 3. The ebuild lists its dependency on sox twice. 4. Agreed on using /var/lib rather than /etc for the web-edited configuration file. 5. Note the updated Audio-FLAC-Header ebuild at bug 103940. This is another case of slimserver being more recent that cpan. I hope to review all other slimserver cpan modules for the same problem later today. 6. I am trying to understand the rationale for the mechanism where init.d/slimserver generates /usr/lib/slimserver/convert.conf (the standard slimserver configuration file) from /etc/slimserver/formats.conf and /etc/slimserver/convert.conf: a. it provides a way to compose encoding/decoding/transcoding steps (logic in init.d/slimserver, formats_update). This is nice, but I think slimserver can already do that itself. b. it provides a way to separate user-supplied and ebuild-supplied configuration. This is definitely good, and a big omission in the standard slimserver. The current mechanism has the disadvantage that the gentoo configuration files have a very different format (both syntactically and semantically) to the upstream standard. Maybe Im missing something, but would it be better to generate convert.conf from a simple concatenation of the files in an /etc/slimserver/convert.conf.d? I'm having a problem getting slimserver running again... not sure what the problem is, but Slimserver starts but I can't get into the web config (unable to establish connection). When I try to stop slimserver, it replies with "[!!]". <p>If someone can help me out here, i'd be quite pleased. Re: comment #145. Michael, you might have some details recorded in the slimserver log file. /var/log/slimserver/slimserver.log FYI regarding XML RPC's dependency on apache in comment #126, it looks like this may have been fixed with a mod_perl use flag added to the dev-perl/RPC-XML ebuild. http://bugs.gentoo.org/show_bug.cgi?id=117587 I've briefly tested it and it seems to work. In the ebuild, it creates a new user with "enewuser slimserver -1 /bin/false /usr/lib/slimserver slimserver" This line should be "enewuser slimserver -1 -1 /usr/lib/slimserver slimserver" The former causes an error on my system Tried to emerge the 6.2.1 ebuild on a ~amd64 box and ran into 'emerge: there are no ebuilds to satisfy "dev-perl/Tie-Cache-LRU"" errors'. Realding the bug thread I thougth the it should work on an ~amd64 box, but it does not. I might be interested in maintaining slimserver in portage (since I hope my new Squeezebox3 should arrive soon). But before it will go into portage I have some questions and things is like to know (I don't feel like reading 150 comments): 1. What is the current state of the ebuild and scripts? (where do I get them, is it the ones attached to this bug...?) 2. Are there any know problems and in the case there are: What are the problems and are there any know solution? 3. Does the ebuild use the perl modules that ships with slimserver or does it use the modules in portage (i.e., does this bug really depend on all those perl module inclusion bugs?) 4. ... So what i'm generally asking for is some kind of summery of the current status. Ups... I forgot to ask, how about the licenses? (In reply to comment #150) > I might be interested in maintaining slimserver in portage (since I hope my new > Squeezebox3 should arrive soon). > > But before it will go into portage I have some questions and things is like to > know (I don't feel like reading 150 comments): > 1. What is the current state of the ebuild and scripts? (where do I get them, > is it the ones attached to this bug...?) The latest ebuild + perl ebuilds can be found at http://files.ged.dynodns.net/slimserver/slimserver-6.2.1-r1.tar.gz I dont belive it is attached to this bug (Which I'm currently having problems with, as I have gentoo on sparc, I belive it's a perl problem, but I havent tracked it down it :( ) > 2. Are there any know problems and in the case there are: What are the problems > and are there any know solution? I belive details of all the problems with this ebuild can be found from comment 144 and below > 3. Does the ebuild use the perl modules that ships with slimserver or does it > use the modules in portage (i.e., does this bug really depend on all those perl > module inclusion bugs?) It uses the modules from portage, so yes it does depend on all thoes perl modules > 4. ... > > So what i'm generally asking for is some kind of summery of the current status. > It's hard to say the current state, I can only speak for it on sparc and currently it's broken (on my box anyway) finally "SlimServer is released under the Open Source GPL license" James Trying to emerge slimserver on an ~AMD64 system (using the HOWTO in http://files.ged.dynodns.net/slimserver/). 1. No need to add the packages listed there in package.keywords in /etc/portage/package.keywords. They all seem to be in portage now (or in the overlay?), but I had to add "dev-perl/Class-Virtual x86" as this is not marked usable on AMD64. 2. Get the following error when trying to emerge slimserver * Adding group 'slimserver' to your system ... * - Groupid: next available * Adding user 'slimserver' to your system ... * - Userid: 104 * Do not specify /bin/false yourself, use -1 !!! ERROR: media-sound/slimserver-6.2.1-r1 failed. Call stack: ebuild.sh, line 1542: Called dyn_setup ebuild.sh, line 654: Called pkg_setup slimserver-6.2.1-r1.ebuild, line 266: Called enewuser 'slimserver' '-1' '/bin/false' '/usr/lib/slimserver' 'slimserver' eutils.eclass, line 489: Called die !!! Pass '-1' as the shell parameter !!! If you need support, post the topmost build error, and the call stack if relevant. Changing 'bin/false' in -1 (as suggested by the error message) allows the emerge to work 3. The init script does not give any error message but slimserver is not started. In the logfile I get the following error: 2006-03-31 22:56:19.7174 DBD::SQLite::db tables failed: not an error(21) at dbdimp.c line 398 at /usr/lib64/slimserver/Slim/DataStores/DBI/DataModel.pm line 164. DBD::SQLite::db tables failed: not an error(21) at dbdimp.c line 398 at /usr/lib64/slimserver/Slim/DataStores/DBI/DataModel.pm line 164. Anyone seen this error? I've just emerged all the latest packages (including Perl), and this one crops up in my slimserver log;
Can't locate object method "audio_size" via package
"Slim::DataStores::DBI::LightWeightTrack" at /usr/lib/slimserver/Slim/Player/Source.pm line 1511 (#1)
(F) You called a method correctly, and it correctly indicated a package
functioning as a class, but that package doesn't define that particular
method, nor does any of its base classes. See perlobj.
Uncaught exception from user code:
Can't locate object method "audio_size" via package "Slim::DataStores::DBI::LightWeightTrack" at /usr/lib/slimserver/Slim/Player/Source.pm line 1511.
at /usr/lib/slimserver/Slim/Player/Source.pm line 1511
Slim::Player::Source::openSong('Slim::Player::Squeezebox2=ARRAY(0x9edbfe4)', 'undef') called at /usr/lib/slimserver/Slim/Player/Source.pm line 412
Slim::Player::Source::playmode('Slim::Player::Squeezebox2=ARRAY(0x9edbfe4)', 'play') called at /usr/lib/slimserver/Slim/Player/Source.pm line 810
Slim::Player::Source::jumpto('Slim::Player::Squeezebox2=ARRAY(0x9edbfe4)', 'undef') called at /usr/lib/slimserver/Slim/Control/Command.pm line 754
Slim::Control::Command::execute('Slim::Player::Squeezebox2=ARRAY(0x9edbfe4)', 'ARRAY(0x9eeb9e8)', 'CODE(0x924376c)', 'ARRAY(0xa3571ac)') called at /usr/lib/slimserver/Slim/Web/HTTP.pm line 674
Slim::Web::HTTP::processURL('HTTP::Daemon::ClientConn=GLOB(0x9e3ba94)', 'HTTP::Response=HASH(0x9eec488)', 'HASH(0xa359df8)') called at /usr/lib/slimserver/Slim/Web/HTTP.pm line 539
Slim::Web::HTTP::processHTTP('HTTP::Daemon::ClientConn=GLOB(0x9e3ba94)') called at /usr/lib/slimserver/Slim/Networking/Select.pm line 111
Slim::Networking::Select::select(0.995901107788086) called at /usr/lib/slimserver/slimserver.pl line 634
main::idle() called at /usr/lib/slimserver/slimserver.pl line 570
Yes, experienced the same problem after doing 'emerge -uD world' which updated several Perl packages. Going back to dev-perl/DBI-1.48 and dev-perl/Class-DBI-3.0.1 resolved it, though. Don't know if you need the old versions for both or just Class-DBI. Tried with DBI only first and it didn't work. Have no idea what changed with the new versions. Regards, ...urs Alright guys, I'm back from the dead. A busy semester at school and traveling to California for a summer internship has kept me busy. Here's the deal. I saw all the breakage with DBI, and it's because I was trying to use the latest DBI, whereas SlimServer ships with a significantly older version. A lot of the headaches here have stemmed from trying to use Gentoo perl modules when SlimServer ships older, but working, versions. I have modified the installation scripts on my machine to only use and build the tools as delivered by the SlimServer team. Also, moving back to using the SlimServer package eliminates the dependencies on all these other new, obscure perl modules, so killing those deps will *hopefully* speed the acceptance of this into portage. I'm killing the deps now, and will attach updated files soon. Created attachment 87174 [details]
files/slimserver.initd
New init.d script, with the following fixes:
- Used grep -v and echo to edit settings, to avoid problems when one
is missing from slimserver.conf already. This used to be a problem if
autolocating iTunes libraries, because the XML setting would get
omitted. These issues are fixed now.
- Removed old edits to fix problems with timeFormat breaking the
configuration files. Upstream fixes now present, so we were
actually causing problems instead of fixing them.
Created attachment 87175 [details, diff]
files/slimserver-6.2.2.patch
Updated patch for 6.2.2. Notable changes:
- Removing code that sets $0 in slimserver.pl done away with; upstream changed
the code so that it only gets set on Win32, so our problem is gone.
- No need to edit DBI code any more, now that we're using only the modules
provided by upstream.
Created attachment 87176 [details]
slimserver-6.2.2.ebuild
Upgraded ebuild to SlimServer 6.2.2. Other changes:
- No longer depends on MySQL or PostgreSQL if you have those
USE flags.
- Only use perl modules shipped by upstream package. Removes
many module dependencies created by us that were not in portage.
Added code to use upstream's code to auto-build necessary binary
packages, so it should be platform-independent.
Created attachment 87177 [details]
files/formats.conf-ffmpeg
Update FFmpeg decoder list to fix various issues:
- No longer use -hq, which has been removed, despite still being
in the man pages.
Created attachment 87178 [details]
files/formats.conf-other
Update "other" decoder config to fix issues noted by users. Should work as advertised.
Hello folks, I just got tired to problems running stndard Slimserver on Gentoo and installed slimserver-6.2.2.ebuild. FLAC files play ok, but I have challenges with MP3 files. Log files says "couldn't open song". What's wrong? any ideas? The machine is x86. /var/log/slimserver/slimserver.log: 2006-06-15 19:22:59.8094 ERROR: Couldn't open song. 2006-06-15 19:23:00.3934 ERROR: Couldn't gotoNext, stopping 2006-06-15 19:23:09.1582 ERROR: Couldn't open song. 2006-06-15 19:23:09.5804 ERROR: Couldn't gotoNext, stopping 2006-06-15 19:23:16.0754 ERROR: Couldn't open song. I managed to fix the MP3 playback problem myself. The problem lied in "/etc/conf.d/slimserver" -file. SLIM_INPUT_FORMATS did not include MP3 by default. was: SLIM_INPUT_FORMATS="wav aif ogg flc" I updated this to: SLIM_INPUT_FORMATS="wav aif ogg flc mp3" Did you have USE="mp3" (and optionally USE="encode") when you emerged the slimserver software? It should enable mp3 by default when you have USE="mp3". If you have USE="-mp3" (or just don't have USE="mp3") it will disable mp3 support by default, which I suspect is what happened. Add mp3 to your USE flags and this should not be an issue again. Also, it is in your best interest to adjust the USE flags first so that any required decoding libraries are RDEPENDed on by the ebuild. - Paul First, huge thanks to Paul and everyone else for the continued maintenance of this ebuild :) The latest 6.2.2 version emerged and started without problems. There is one issue in it's operation though, I am wondering if it is related to comment #160: I can no longer tune into my favourite mms:// radio station. The error is: mms://203.12.234.146/kiss: I/O error occured Usually that means that input file is truncated and/or corrupted. ffmpeg version CVS, build 3342336, Copyright (c) 2000-2004 Fabrice Bellard configuration: --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-shared-pp --enable-shared --disable-static --extra-ldflags= --enable-mmx --disable-altivec --disable-debug --enable-mp3lame --enable-a52 --disable-a52bin --enable-audio-oss --disable-v4l --enable-dv1394 --enable-dc1394 --disable-pthreads --enable-xvid --enable-libogg --enable-vorbis --enable-theora --enable-dts --disable-network --enable-zlib --enable-ffplay --enable-faad --enable-faac --disable-faadbin --cc=i686-pc-linux-gnu-gcc --enable-gpl --enable-pp --disable-opts --disable-strip --build=i686-pc-linux-gnu built on Jun 12 2006 15:40:07, gcc: 4.1.1 (Gentoo 4.1.1) xine and mplayer can play the mms:// without problems - this is what is returned by mplayer. ASF file format detected. ========================================================================== Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders AUDIO: 44100 Hz, 1 ch, s16le, 48.0 kbit/6.81% (ratio: 6003->88200) Selected audio codec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg)) ========================================================================== I thought the "custom" Audio::WMA Module in comment #136 and my comment #138 has been altered. I see that Audio-WMA-0.8.ebuild lists SLIM_VERSION="6.2.1" Changing that line to 6.2.2 and digesting then re-emerging unfortunately made no difference. Can anyone confirm or offer a fix, or is this an upstream problem? What's the full URL for that mms:// stream? It looks to me like there's a space in the name that's causing it to get split into two (or more) parts when passed to the FFmpeg command. Regarding Audio::WMA (and Audio-WMA), see comment #159. I have reverted to using the packages shipped by Slim Devices to eliminate compatibility problems that we started seeing, particularly with DBI and DBD. All the extraneous ebuilds previously installed by slimserver can be removed using emerge --depclean or something similar. Please heed *all* warnings about --depclean, it's not safe. Use something like etcatmur's "dep." Anyway, let me know what that URL is and I'll see if I can figure out how to fix it. The URL is mms://203.12.234.146/kiss or http://www.mp3.com.au/KissFM/stream.asx for the ASX container that holds the mms:// Created attachment 90462 [details] slimserver-6.2.2-r1.ebuild problem fixed as detailed in comment #153, as I also found this problem. I have also added ~sparc and now have it running under sparc :) Cheers Paul for all the work! Thanks for attaching that fix; I'd completely forgotten about it (and it's super trivial). I've fixed my local copies of the ebuild to match, so any future updates from me should be free of the problem mentioned in comment #153. Has anyone else tryed the ebuild on 6.3.0? I currently have it running, after changing the name of the ebuild and patch script. But I'm not sure if the patch got applyed correctly. Anyway it seems to running fine. I have not tried it on 6.3.0 yet. I did see that 6.3.0 is out, so a new version with altered patches will be coming sometime this week. I'm currently busy on another small project of mine, so it may take a bit. But rest assured that I didn't totally miss the release of 6.3.0. - Paul Confirming slimserver 6.2.2-r1 runs under x86 hardened. Calculating dependencies... done! [ebuild R ] media-sound/slimserver-6.2.2-r1 USE="aac encode ffmpeg flac mp3 vorbis wma -musepack -shorten" emerge --info (truncated) Portage 2.1-r2 (hardened/x86/2.6, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-hardened-r11 i686) ================================================================= System uname: 2.6.16-hardened-r11 i686 AMD Athlon(TM) MP 2800+ Gentoo Base System version 1.12.4 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -march=athlon-mp" CHOST="i686-pc-linux-gnu" (In reply to comment #171) > I have not tried it on 6.3.0 yet. I did see that 6.3.0 is out, so a new > version with altered patches will be coming sometime this week. Hello all, Any news on that 6.3.0 update? By the way, thanks for all the hard work to everyone. Reading the comment list on this bug to me shows Gentoo at its finest. I've created my own ebuilds for slimserver here: http://dev.gentoo.org/~twp/slimserver/ There's some discussion about them here: http://forums.slimdevices.com/showthread.php?t=28428 I hadn't searched for existing slimserver ebuilds, so I'll take ownership of this bug and combine the best aspects of both sets of ebuilds. Cheers, Tom Dear All, I propose to commit a new set of slimserver ebuilds when 6.5.1 is released. The following attachments are what I plan to commit to portage. TODO: - check that dev-db/mysql is built_with_use innodb Feedback appreciated. Cheers, Tom Created attachment 101321 [details]
slimserver-6.5.0.ebuild
Created attachment 101322 [details, diff]
slimserver-bootstrap-gentoo.patch
Created attachment 101323 [details, diff]
slimserver-mDNSResponderPosix-107.patch
Created attachment 101324 [details]
slimserver.init.d
Created attachment 101325 [details]
slimserver.conf.d
this work for the innodb test:
if ! built_with_use dev-db/mysql innodb; then
eerror "dev-db/mysql wasn't built with innodb support, please re-emerge with USE=innodb."
die "need dev-db/mysql built with innodb USE flag" fi
but... my mysql-5 has no innodb use flag
and for the others: you need #154221 ebuild as a dependency
This has just gone into portage, marked ~x86. Be warned that if you've spun your own slimserver ebuild then it might get overwritten if you blindly do an emerge -u world! Ebuilds are: media-sound/slimserver media-sound/softsqueeze (simple softsqueeze wrapper) Let me know of any problems, if there are none then I'll close this bug on Nov 20. Tom Apologies for falling off the face of the earth, but I finally got a chance to look at the ebuilds attached here. I'd like to discuss the decision to depend on Gentoo's perl ebuilds intead of using the bundle that Slim Devices ships. I tried using Gentoo ebuilds for perl modules a while back, and found that, over time, conflicts arose that would completely break SlimServer. Upstream depends on some very old versions of perl modules that are no longer in the portage tree, and the new modules are not wholly backwards compatible. I feel like we'd be safer with the way my previous ebuild did things, which is just to compile all the perl modules from upstream, and put them in /usr/lib/slimserver with everything else, where they won't interfere with the rest of the system. Your thoughts? (In reply to comment #183) > I tried using Gentoo ebuilds for perl modules a while back, and found that, > over time, conflicts arose that would completely break SlimServer. That's also the conclusion i came to when i worked on v5.4 ebuilds. I don't know if that's still true, but at that time the Slimserver's Perl tree was heavily patched, and actually impossible to replace with Gentoo's packages (see comment #16). From the ebuilds in now Portage...
>>> Emerging (6 of 6) media-sound/slimserver-6.5.0 to /
* SlimServer_v6.5.0.no-cpan-arch.tar.gz MD5 ;-) ... [ ok ]
* SlimServer_v6.5.0.no-cpan-arch.tar.gz RMD160 ;-) ... [ ok ]
* SlimServer_v6.5.0.no-cpan-arch.tar.gz SHA1 ;-) ... [ ok ]
* SlimServer_v6.5.0.no-cpan-arch.tar.gz SHA256 ;-) ... [ ok ]
* SlimServer_v6.5.0.no-cpan-arch.tar.gz size ;-) ... [ ok ]
* checking ebuild checksums ;-) ... [ !! ]
!!! Digest verification failed:
!!! /usr/portage/media-sound/slimserver/slimserver-6.5.0.ebuild
!!! Reason: Filesize does not match recorded size
!!! Got: 3861
!!! Expected: 3756
Obviously "emerge -av --digest slimserver" fixes this.
Now testing.
This would also work on sparc, if it was not for dev-perl/YAML-Syck which does not have the ~sparc keyword as well :(. Am I correct in thinking that to have that addressed I need to file a bug for dev-perl/YAML-Syck? Thanks for the feedback folks. - The digest has been fixed in CVS. - In theory, everything should work on other ARCHes as long as the deps are available. You'll need to submit a bug to get dev-perl/YAML-Syck keyworded for sparc since I can't test that ARCH and so can't keyword it. - Regarding using Gentoo ebuilds for the Perl modules, let's see if people run into problems. The build-perl-modules.pl script downloads and installs pristine versions of the modules, so there shouldn't be any SlimServer-specific modifications to them. If we do encounter problems then I'll switch to the build-perl-modules.pl approach. Cheers, So what would it take to get this ebuild into ~amd64 Anthony I don't know, but for what it's worth, I've been running slimserver on ~amd64 for a long time now; well over a year, at least. Granted, it wasn't these particular ebuilds, but it runs fine for me. Also, on amd64, sometimes I cheat by adding x86 and ~x86 to an ebuild's keywords in /etc/portage/package.keywords. This is, of course, officially discouraged, but it's worked for me on one or two packages. (In reply to comment #188) > So what would it take to get this ebuild into ~amd64 > > Anthony > Yeah, could we get this keyworded ~amd64 please. sparc and amd64 ARCH teams, please could you keyword media-sound/slimserver ~sparc and ~amd64 respectively. Cheers, Tom At first: Thanks a lot Tom for your efforts. But I still noticed the following: The slimserver ebuild in portage seems to be missing a rdepend for a certain baselayout version, since the init script uses the --env parameter to start-stop-daemon which is not yet present in baselayout 1.11.14 resulting error: pilot ~ # /etc/init.d/slimserver start * Starting slimserver ... start-stop-daemon: unrecognized option `--env' Try `start-stop-daemon --help' for more information. [ !! ] Thanks, I've modified the ebuild to do: HOME=/opt/slimserver start-stop-daemon ... rather than introducing a dependency on baselayout. Regards, Tom Hopefully most of the bugs in the ebuild have been fixed now. Unless there are any major problems I'll mark this bug FIXED in a week or so (27 Nov). I would be interested to hear whether people would prefer slimserver to run its own instance of MySQL (which is the case at the moment), or if they would prefer it to use the system instance. If there are no strong opinions then I'll keep it as-is (own instance), if some of you would like it to use the system instance then I'll make the behaviour controllable by a USE flag. Cheers, Tom Personally I would prefer slimserver using the system instance. I wasn't even aware that it used its own instance. Actually, I have no idea *why* it might run its own instance in the first place. Is there any advantage other than confusing the system administrator? Ole. As I understand it, SlimServer using its own instance of MySQL has a number of advantages: - works "out of the box" - doesn't interfere with your existing MySQL setup - a little more secure (only accepts connections from localhost) - a little easier to manage (not affected by changes to the system instance) Regards, Tom External software like MySQL isn't what I was talking about. SlimServer provides a giant tarball of perl modules, both compiled and perl-only, that are heavily patched from their CPAN counterparts, which Gentoo would install. In some cases, SlimServer uses archaic versions that are no longer available on CPAN. If we use our Gentoo ebuilds (and thus CPAN packages), it's almost guaranteed that we will cause incompatibility problems later on. SlimServer comes with a tarball that we can compile as part of SlimServer, and jail inside /usr/lib/slimserver, so that SlimServer sees its custom modules, and the rest of your system is *unaffected.* Hi Paul, MySQL is a separate issue to Perl modules. The only Perl modules that are installed via portage are those which are either: - not present in SlimServer_v6.5.0.no-cpan-arch.tar.gz, or - built by the build-perl-modules.pl script build-perl-modules.pl downloads pristine versions of the modules, which do not have any modifications by SlimDevices. Tom Just tested successfully here with the latest version, I'd feel strongly leaving MySQL where it is (embedded) as the default option. Let those interested in hooking in to their System MySQL installation do so, by all means, but I'd like to have it 'just work' and not have to config extra bits unless I have to... My $0.05 :) (In reply to comment #188) > So what would it take to get this ebuild into ~amd64 All it takes is an amd64 arch tester, some time and an amd64 dev willing to commit this. Though an amd64 team that is not being completely swamped would also help ;) Anyways, this emerges and works fine for me on amd64 and is ready for the almighty ~amd64 keyword ;) Portage 2.1.2_rc2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.18-suspend2-Dudebox-Edition x86_64) ================================================================= System uname: 2.6.18-suspend2-Dudebox-Edition x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.6 Last Sync: Sun, 19 Nov 2006 03:30:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r6 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -msse3 -Os -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k8 -msse3 -Os -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache collision-protect distcc distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict test userfetch userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://server/gentoo-portage" USE="amd64 X alsa berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dlloader dri dvd dvdr dvdread eds elibc_glibc emboss encode esd fam firefox fortran gdbm gif gpm gstreamer gtk gtk2 hal iconv input_devices_keyboard input_devices_mouse isdnlog jpeg kde kdeenablefinal kdehiddenvisibility kernel_linux libg++ mad mikmod mp3 mpeg ncurses nls nptl nptlonly objc objc++ ogg oss pam pcre pdf perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_radeon vorbis xml xorg xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS if the dude says so it must be true - ~amd64 added Marking CLOSED. Thanks to all who helped out. I'll stick with SlimServer using its own instance of MySQL for now, although the option to use the system instance might get added as an enhancement later. If problems with Perl modules get reported then those will get fixed too, but I'll wait for the bug reports first. Cheers, Tom |
