New user's registration have been closed due to high spamming and low trafic on this forum. Please contact forum admins directly if you need an account. Thanks !
ryz wrote:
There's a stand-alone version that includes libraries for every supported processor and that will probably work as is (I did not verify this because I intended to stick to package manager), but the (ARM) package is much smaller and did not find the required Perl objects. Clearly these are not part of the package (or it references the wrong library path, using system instead of private).
And even if all perl objects were included in the package this would finally lead to a vast mixture of different perl versions on the system! Debian-Squeeze comes with perl v5.10.1-17, while the bundled package is for Perl 5.8-5.14 (at least the slimdevices page states that).
How shall any package manager handle this? Ok, Linux is generally able to manage such situations, you can install different versions either both or make selection via "alternatives". But, if logitechmediaserver supplies perl modules, they should be listed correctly in /DEBIAN/control file of the *.deb.
Kind regards,
Ingo
UNIX is user friendly, it's just picky about who its friends are.
ryz wrote:
There's a stand-alone version that includes libraries for every supported processor and that will probably work as is (I did not verify this because I intended to stick to package manager), but the (ARM) package is much smaller and did not find the required Perl objects. Clearly these are not part of the package (or it references the wrong library path, using system instead of private).
And even if all perl objects were included in the package this would finally lead to a vast mixture of different perl versions on the system! Debian-Squeeze comes with perl v5.10.1-17, while the bundled package is for Perl 5.8-5.14 (at least the slimdevices page states that).
How shall any package manager handle this? Ok, Linux is generally able to manage such situations, you can install different versions either both or make selection via "alternatives". But, if logitechmediaserver supplies perl modules, they should be listed correctly in /DEBIAN/control file of the *.deb.
Kind regards,
Ingo
The perl modules are bundled privately, i.e. they are not exposed to the system as whole. They can be located in /usr/share/squeezeboxserver/CPAN/ and the "arch" directory contains compiled version for 5.8, 5.10, 5.12, and 5.14.
And even if all perl objects were included in the package this would finally lead to a vast mixture of different perl versions on the system! Debian-Squeeze comes with perl v5.10.1-17, while the bundled package is for Perl 5.8-5.14 (at least the slimdevices page states that).
How shall any package manager handle this? Ok, Linux is generally able to manage such situations, you can install different versions either both or make selection via "alternatives". But, if logitechmediaserver supplies perl modules, they should be listed correctly in /DEBIAN/control file of the *.deb.
Kind regards,
Ingo
The perl modules are bundled privately, i.e. they are not exposed to the system as whole. They can be located in /usr/share/squeezeboxserver/CPAN/ and the "arch" directory contains compiled version for 5.8, 5.10, 5.12, and 5.14.
/Carl
Thanks for the crarification Carl.
Does that really meen, I can safely purge those 104 packages which
ingo2 wrote:
And even if all perl objects were included in the package this would finally lead to a vast mixture of different perl versions on the system! Debian-Squeeze comes with perl v5.10.1-17, while the bundled package is for Perl 5.8-5.14 (at least the slimdevices page states that).
How shall any package manager handle this? Ok, Linux is generally able to manage such situations, you can install different versions either both or make selection via "alternatives". But, if logitechmediaserver supplies perl modules, they should be listed correctly in /DEBIAN/control file of the *.deb.
Kind regards,
Ingo
The perl modules are bundled privately, i.e. they are not exposed to the system as whole. They can be located in /usr/share/squeezeboxserver/CPAN/ and the "arch" directory contains compiled version for 5.8, 5.10, 5.12, and 5.14.
/Carl
Thanks for the crarification Carl.
Does that really meen, I can safely purge those 104 packages which
Thanks Johannes,
I now also cleaned up my packages and right - all seems to be fine. I just was concerned because also the web-interface uses Perl.
At this occasion another question:
is there any special reason why Debian-updates and -security are not in /etc/apt/sources.list?
Shouldn't we add as well
No, we don't let debian updates through to our customers without testing first. You never know what implications their package updates would get on the B3 system, therefor we always pull such changes on our regular updates, to make sure we test before release anything to our customers.
/Johannes (Excito co-founder a long time ago, but now I'm just Johannes)
I'm a bit late in this thread...
Install went OK, except Apache didn't come up after the restart (I had modified the certificate names in /usr/share/bubba-frontend/apache.site, and also deleted the original certificate files for good measure ).
I have the same issue as reported twice at the very start of this thread. As far as I can see, there was never any response to this issue:
Murtagh wrote:I just installed the 2.4 upgrade on my B3, and it in gerneral went very smoothly. The only issue I have is I am not able to access the new DAAP server, and the release notes don't mention which new server is being utilized so I could chase the issue myself.
I am using Banshee 2.2.1 on Ubuntu Linux 11.10 (Oneric) to access the DAAP service. The service seems to be at least partally active because I am able to see the service advertising "My Music on" my server name, but when I attempt to access the music, Banshee complains with the following:
"Unable to Connect to Music Share
Common reasons for connection failures
->The provided credentials are invalid
->The Login process was cancelled
-> Too many users are connected to the share
-> The music share is hosted by iTunes 7"
The first two suggestions don't seem likely, and the third is untrue.
).