Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On 03/29/2015 08:01 PM, Niko Tyni wrote: Glad to see progress on this! On Sun, Mar 29, 2015 at 05:46:44PM +0200, Kasper Loopstra wrote: However, I am quite sure that I removed /usr/local/share before starting off with the upgrade, so perhaps there is something wrong with the upgrade path between wheezy and jessie. So below is what's in the /usr/local/share after an upgrade. Is there anything wrong here? Or shouldn't I have removed /usr/local/share without recreating it with correct permissions? I think whatever recreated /usr/local/share without world read+execute bits is buggy and should be fixed before the release. Now we just need to find it. What's your umask setting during the upgrade? 0022 root@chloromethane:/usr/local# ls -la share/ total 20 drwxr-x--x+ 5 root root 4096 Mar 29 13:35 . drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 .. drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 ca-certificates drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 emacs drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 texmf The time stamps seem to suggest that the package that created /usr/local/share/texmf is to blame. However, that would be tex-common AFAICS, but its post-installation script doesn't seem to do this. In fact, it will not create /usr/local/share/texmf at all if /usr/local/share is missing. if you are able to recreate this, would it be possible for you to first remove /usr/local/share and then upgrade piecemeal, maybe starting with the tex* packages you have installed? Perhaps that would pinpoint the guilty package. I'll try, but piecemeal upgrades are kind of difficult (I tried for spamassassin), and I see things pull in so much dependencies it's almost the entire upgrade anyway. Is there some apt-get magic I am missing? Thanks, Kasper. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On 03/29/2015 05:02 PM, gregor herrmann wrote:
On Sun, 29 Mar 2015 16:44:07 +0200, Kasper Loopstra wrote:
I'm not sure where to go from here? Should I wait until #781120 is
resolved in jessie, or continue trying to figure out what's wrong?
The fix will only print a better error message, i.e. _which_ file
emits the Permission denied message.
But you should be able to find this out by something like:
# su -l debian-spamd
$ perl -MList::Util -e 'print $INC{strict.pm}'
/usr/share/perl/5.20/strict.pm$
I tried, but apparently there's more wrong than just strict.pm.
root@chloromethane:~# su -l debian-spamd
$ perl -MList::Util -e 'print $INC{strict.pm}'
Can't locate List/Util.pm: Permission denied.
BEGIN failed--compilation aborted.
No luck with perl -V either:
$ perl -V
Can't locate Config.pm: Permission denied.
BEGIN failed--compilation aborted.
$ perl -e print \@INC\
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.2
/usr/local/share/perl/5.20.2 /usr/lib/x86_64-linux-gnu/perl5/5.20
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20
/usr/share/perl/5.20 /usr/local/lib/site_perl .$
for i in $(perl -e print \@INC\); do find $i -type d -not -perm
-o=rx; done$
find: `/usr/local/lib/x86_64-linux-gnu/perl/5.20.2': No such file or
directory
find: `/usr/local/share/perl/5.20.2': Permission denied
find: `/usr/local/lib/site_perl': No such file or directory
./sa-update-keys
./.spamassassin
$
root@chloromethane:~# cd /usr/local/
root@chloromethane:/usr/local# ls -la
total 20
drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 .
drwxr-xr-x 12 root root 4096 Mar 29 12:50 ..
drwxr-xr-x+ 4 root root 4096 Mar 29 13:40 lib
drwxr-x---+ 2 root root 4096 Mar 29 12:31 sbin
drwxr-x---+ 5 root root 4096 Mar 29 13:35 share
chmod o+x share
And everything works after apt-get install -f.
Thank you very much!
However, I am quite sure that I removed /usr/local/share before starting
off with the upgrade, so perhaps there is something wrong with the
upgrade path between wheezy and jessie. So below is what's in the
/usr/local/share after an upgrade. Is there anything wrong here? Or
shouldn't I have removed /usr/local/share without recreating it with
correct permissions?
root@chloromethane:/usr/local# ls -la share/
total 20
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 .
drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 ..
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 ca-certificates
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 emacs
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 texmf
root@chloromethane:/usr/local# ls -laR share/
share/:
total 20
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 .
drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 ..
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 ca-certificates
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 emacs
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 texmf
share/ca-certificates:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 .
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 ..
share/emacs:
total 16
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 .
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 ..
drwxrwsr-x+ 3 root staff 4096 Mar 29 13:35 24.4
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 site-lisp
share/emacs/24.4:
total 12
drwxrwsr-x+ 3 root staff 4096 Mar 29 13:35 .
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 ..
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 site-lisp
share/emacs/24.4/site-lisp:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 .
drwxrwsr-x+ 3 root staff 4096 Mar 29 13:35 ..
share/emacs/site-lisp:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:35 .
drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 ..
share/texmf:
total 8
drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 .
drwxr-x--x+ 5 root root 4096 Mar 29 13:35 ..
root@chloromethane:/usr/local#
Thanks again to all,
Kasper Loopstra.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
Dear Niko, I recently did a new upgrade on a copy of the same system, but before the upgrade I moved everything in /usr/local to a backup location, and only replaced some scripts in /usr/local/sbin we use to restart our LDAP server and such. On 03/24/2015 08:35 PM, Niko Tyni wrote: Also, just /usr/local/lib/site_perl doesn't explain your problem as strict.pm should be earlier on the search path. Is /etc/perl, /usr/local/share/perl, /usr/local/lib, or something like that non-readable too? Does /usr/share/perl/5.20/strict.pm exist? root@chloromethane:/usr/local# stat /usr/share/perl/5.20/strict.pm File: ‘/usr/share/perl/5.20/strict.pm’ Size: 1006Blocks: 8 IO Block: 4096 regular file Device: 807h/2055d Inode: 272273 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2015-03-29 13:00:59.525885644 +0200 Modify: 2015-03-01 23:35:21.0 +0100 Change: 2015-03-29 13:00:32.550411188 +0200 Birth: - 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 This is worse than it was when you started. It looks like you either removed permissions somewhere instead of adding them, or your file system is getting corrupted somehow. The file libperl.so.5.20 should be in /usr/lib/x86_64-linux-gnu and world readable. It's there, and a symlink to libperl.so.5.20.2, which is 644. Additionally, this is a fresh clone, so I'm not getting the .so error anymore, now it's just the permission denied. 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? Generally the directories should me root:root, mode 755. For reference, this is how the @INC permissions and symlinks look on my system: drwxr-xr-x 5 root root 4096 Oct 5 2013 /etc/perl lrwxrwxrwx 1 root root 6 Feb 27 20:14 /usr/lib/x86_64-linux-gnu/perl/5.20 - 5.20.2 drwxr-xr-x 32 root root 4096 Mar 1 20:47 /usr/lib/x86_64-linux-gnu/perl/5.20.2 drwxr-xr-x 93 root root 4096 Mar 21 21:16 /usr/lib/x86_64-linux-gnu/perl5/5.20 drwxr-xr-x 189 root root 12288 Feb 28 00:22 /usr/share/perl5 lrwxrwxrwx 1 root root 6 Feb 27 20:14 /usr/share/perl/5.20 - 5.20.2 drwxr-xr-x 58 root root 12288 Mar 1 20:47 /usr/share/perl/5.20.2 but if you've changed other permissions as well, it becomes rather hard to help. Possibly the best start is to reinstall perl, perl-base, perl-modules, and libperl5.20 with dpkg. apt-get --reinstall install perl perl-base perl-modules lib perl5.20 [...] Preparing to unpack .../perl-modules_5.20.2-2_all.deb ... Unpacking perl-modules (5.20.2-2) over (5.20.2-2) ... Preparing to unpack .../perl_5.20.2-2_amd64.deb ... Unpacking perl (5.20.2-2) over (5.20.2-2) ... Preparing to unpack .../libperl5.20_5.20.2-2_amd64.deb ... Unpacking libperl5.20 (5.20.2-2) over (5.20.2-2) ... Processing triggers for man-db (2.7.0.2-5) ... Setting up libperl5.20 (5.20.2-2) ... Setting up perl-modules (5.20.2-2) ... Setting up perl (5.20.2-2) ... [...] Setting up spamassassin (3.4.0-6) ... Can't locate strict.pm: Permission denied at /usr/bin/sa-update line 23. BEGIN failed--compilation aborted at /usr/bin/sa-update line 23. dpkg: error processing package spamassassin (--configure): subprocess installed post-installation script returned error exit status 13 dpkg: dependency problems prevent configuration of sa-compile: sa-compile depends on spamassassin (= 3.3.2-8); however: Package spamassassin is not configured yet. dpkg: error processing package sa-compile (--configure): dependency problems - leaving unconfigured Additionally, following the advice in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781120 I've ran the following, believing that this should find any files or directories with incorrect permissions: for i in $(perl -e print \@INC\); do find $i -type d -not -perm -o=rx; done for i in $(perl -e print \@INC\); do find $i -type f -not -perm -o=x; done Neither command finds anything, and only complains about /usr/local/lib/x86_64-linux-gnu/perl/5.20.2 /usr/local/share/perl/5.20.2 /usr/local/lib/site_perl not existing. I'm not sure where to go from here? Should I wait until #781120 is resolved in jessie, or continue trying to figure out what's wrong? 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? I'm not yet convinced this is a perl bug rather than a local problem. Thank you very much for the help with a local configuration issue :) Thanks again, Kasper Loopstra. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On Sun, 29 Mar 2015 16:44:07 +0200, Kasper Loopstra wrote:
Setting up spamassassin (3.4.0-6) ...
Can't locate strict.pm: Permission denied at /usr/bin/sa-update line 23.
BEGIN failed--compilation aborted at /usr/bin/sa-update line 23.
dpkg: error processing package spamassassin (--configure):
subprocess installed post-installation script returned error exit
status 13
dpkg: dependency problems prevent configuration of sa-compile:
sa-compile depends on spamassassin (= 3.3.2-8); however:
Package spamassassin is not configured yet.
dpkg: error processing package sa-compile (--configure):
dependency problems - leaving unconfigured
Now it would be interesting to know where debian-spamd / sa-update
looks for perl modules ...
I'm not sure where to go from here? Should I wait until #781120 is
resolved in jessie, or continue trying to figure out what's wrong?
The fix will only print a better error message, i.e. _which_ file
emits the Permission denied message.
But you should be able to find this out by something like:
# su -l debian-spamd
$ perl -MList::Util -e 'print $INC{strict.pm}'
/usr/share/perl/5.20/strict.pm$
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe
`- NP: Dire Straits: Tunnel Of Love
signature.asc
Description: Digital Signature
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
Glad to see progress on this! On Sun, Mar 29, 2015 at 05:46:44PM +0200, Kasper Loopstra wrote: However, I am quite sure that I removed /usr/local/share before starting off with the upgrade, so perhaps there is something wrong with the upgrade path between wheezy and jessie. So below is what's in the /usr/local/share after an upgrade. Is there anything wrong here? Or shouldn't I have removed /usr/local/share without recreating it with correct permissions? I think whatever recreated /usr/local/share without world read+execute bits is buggy and should be fixed before the release. Now we just need to find it. What's your umask setting during the upgrade? root@chloromethane:/usr/local# ls -la share/ total 20 drwxr-x--x+ 5 root root 4096 Mar 29 13:35 . drwxr-xr-x+ 5 root root 4096 Mar 29 13:14 .. drwxrwsr-x+ 2 root staff 4096 Mar 29 13:34 ca-certificates drwxrwsr-x+ 4 root staff 4096 Mar 29 13:35 emacs drwxrwsr-x+ 2 root staff 4096 Mar 29 13:14 texmf The time stamps seem to suggest that the package that created /usr/local/share/texmf is to blame. However, that would be tex-common AFAICS, but its post-installation script doesn't seem to do this. In fact, it will not create /usr/local/share/texmf at all if /usr/local/share is missing. if you are able to recreate this, would it be possible for you to first remove /usr/local/share and then upgrade piecemeal, maybe starting with the tex* packages you have installed? Perhaps that would pinpoint the guilty package. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On Mon, Mar 23, 2015 at 10:24:50AM +0100, Kasper Loopstra wrote: 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). Yes, it looks like they should be world readable, although I'd be interested in knowing why they aren't. Also, just /usr/local/lib/site_perl doesn't explain your problem as strict.pm should be earlier on the search path. Is /etc/perl, /usr/local/share/perl, /usr/local/lib, or something like that non-readable too? Does /usr/share/perl/5.20/strict.pm exist? 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 This is worse than it was when you started. It looks like you either removed permissions somewhere instead of adding them, or your file system is getting corrupted somehow. The file libperl.so.5.20 should be in /usr/lib/x86_64-linux-gnu and world readable. 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? Generally the directories should me root:root, mode 755. For reference, this is how the @INC permissions and symlinks look on my system: drwxr-xr-x 5 root root 4096 Oct 5 2013 /etc/perl lrwxrwxrwx 1 root root 6 Feb 27 20:14 /usr/lib/x86_64-linux-gnu/perl/5.20 - 5.20.2 drwxr-xr-x 32 root root 4096 Mar 1 20:47 /usr/lib/x86_64-linux-gnu/perl/5.20.2 drwxr-xr-x 93 root root 4096 Mar 21 21:16 /usr/lib/x86_64-linux-gnu/perl5/5.20 drwxr-xr-x 189 root root 12288 Feb 28 00:22 /usr/share/perl5 lrwxrwxrwx 1 root root 6 Feb 27 20:14 /usr/share/perl/5.20 - 5.20.2 drwxr-xr-x 58 root root 12288 Mar 1 20:47 /usr/share/perl/5.20.2 but if you've changed other permissions as well, it becomes rather hard to help. Possibly the best start is to reinstall perl, perl-base, perl-modules, and libperl5.20 with dpkg. 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? No, there are currently no plans to update Perl in any major way before the jessie 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? I'm not yet convinced this is a perl bug rather than a local problem. -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On Tue, Mar 24, 2015 at 09:35:40PM +0200, Niko Tyni wrote: On Mon, Mar 23, 2015 at 10:24:50AM +0100, Kasper Loopstra wrote: 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? No, there are currently no plans to update Perl in any major way before the jessie release. A small follow up on this: I've just filed https://bugs.debian.org/781120 soliciting reports of other similar cases. This may result in a jessie perl change that would at least improve the diagnostics of the error message to include the name of the directory with problematic permissions. This doesn't really solve your issue though... -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
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? Looks like you have ancient modules sitting in /usr/local/ I'd suggest to mode aside /usr/local, upgrade, and then restore /usr/local/ If I'm right, you should have then an upgraded system. But the old libraries in /usr/local will continues to cause problems. Hope this helps -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
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
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
Package: spamassassin Version: 3.4.0-6 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Doing a wheezy/jessie upgrade on a virtualbox clone of our server, we encountered some errors with spamassassin that persisted after a purge and reinstall. The postinstall errors as below. * What exactly did you do (or not do) that was effective (or ineffective)? Purge, reinstall, and a quick glance at the postinstall script did not point to anything specific. Setting up spamassassin (3.4.0-6) ... Can't locate strict.pm: Permission denied at /usr/bin/sa-update line 23. BEGIN failed--compilation aborted at /usr/bin/sa-update line 23. dpkg: error processing package spamassassin (--configure): subprocess installed post-installation script returned error exit status 13 dpkg: dependency problems prevent configuration of sa-compile: sa-compile depends on spamassassin (= 3.3.2-8); however: Package spamassassin is not configured yet. dpkg: error processing package sa-compile (--configure): dependency problems - leaving unconfigured -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages spamassassin depends on: ii adduser 3.113+nmu3 ii init-system-helpers 1.22 pn libarchive-tar-perl none ii libhtml-parser-perl 3.71-1+b3 ii libnet-dns-perl 0.81-2 ii libnetaddr-ip-perl 4.075+dfsg-1+b1 ii libsocket6-perl 0.25-1+b1 ii libsys-hostname-long-perl 1.4-3 ii libwww-perl 6.08-1 ii perl5.20.2-2 ii perl-modules [libio-zlib-perl] 5.20.2-2 Versions of packages spamassassin recommends: ii gnupg 1.4.18-7 ii libio-socket-inet6-perl2.72-1 ii libmail-spf-perl 2.9.0-3 ii perl [libsys-syslog-perl] 5.20.2-2 iu sa-compile 3.4.0-6 ii spamc 3.4.0-6 Versions of packages spamassassin suggests: ii libdbi-perl 1.631-3+b1 ii libio-socket-ssl-perl 2.002-2 ii libmail-dkim-perl 0.40-1 ii perl [libcompress-zlib-perl] 5.20.2-2 ii pyzor 1:0.5.0-2 ii razor 1:2.85-4.1+b1 -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
On Fri, Mar 20, 2015 at 08:54:21AM +0100, Kasper Loopstra wrote: Package: spamassassin Version: 3.4.0-6 Severity: important 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). 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 -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
