Dear Niko, Thank you for the quick response, >> Setting up spamassassin (3.4.0-6) ... >> Can't locate strict.pm: Permission denied at /usr/bin/sa-update line 23. > I assume you have a restricted directory on the default Perl search path > (@INC) that the debian-spamd user can't read, probably under /usr/local ? > (See "perl -V" for the list of directories on @INC). This is correct, in /usr/local/lib/site_perl. Should these be world-readable? I am not that familiar with Perl (beyond editing some specific scripts). After some chmod o+r and +x on directories listed in perl -V, I'm getting new errors:
Setting up spamassassin (3.4.0-6) /usr/bin/perl: error while loading shared libraries: libperl.so.5.20: cannot open shared object file: No such file or directory I am not exactly sure what permissions should be on what files. Any ideas on how to recover this systems Perl back to a usable state? Or should we postpone further testing of the jessie upgrade path until a new version of Perl becomes available in testing? Will that happen before release? As far as I know, the system we're using never had any special Perl stuff happening to it, but it has been upgraded from squeeze (or maybe etch) over the last years. Should I raise a bug with the perl package? Thanks again, Kasper Loopstra. > The perl behaviour changed in such cases with Perl 5.18; from 'perldoc > perl5180delta': > > "require" dies for unreadable files > When "require" encounters an unreadable file, it now dies. It used to > ignore the file and continue searching the directories in @INC [perl > #113422]. > > There is an ongoing discussion at Perl upstream about what's the right > thing to do here, see > > https://rt.perl.org/Public/Bug/Display.html?id=123795 > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
