Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#780830: spamassassin: Fails to install, 'strict.pm, permission denied'
114 views
Skip to first unread message
Kasper Loopstra
Mar 20, 2015, 4:00:03 AM3/20/15
to
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 perl 5.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-perl 2.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-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
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 perl 5.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-perl 2.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-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Niko Tyni
Mar 20, 2015, 4:40:03 AM3/20/15
to
On Fri, Mar 20, 2015 at 08:54:21AM +0100, Kasper Loopstra wrote:
> Package: spamassassin
> Version: 3.4.0-6
> Severity: important
> 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
> Can't locate strict.pm: Permission denied at /usr/bin/sa-update line 23.
(@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
Kasper Loopstra
Mar 23, 2015, 6:00:02 AM3/23/15
to
Dear Niko,
Thank you for the quick response,
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
>
--
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
>> 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).
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
>
--
Dominique Dumont
Mar 23, 2015, 9:40:04 AM3/23/15
to
> 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/
> 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'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
Niko Tyni
Mar 24, 2015, 3:40:03 PM3/24/15
to
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
> >> 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).
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
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?
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?
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?
--
Niko Tyni nt...@debian.org
Niko Tyni
Mar 24, 2015, 4:20:02 PM3/24/15
to
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
> 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.
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...
Kasper Loopstra
Mar 29, 2015, 10:50:02 AM3/29/15
to
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: 1006 Blocks: 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.000000000 +0100
Change: 2015-03-29 13:00:32.550411188 +0200
Birth: -
Additionally, this is a fresh clone, so I'm not getting the .so error
anymore, now it's just the permission denied.
[...]
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) ...
[...]
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.
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?
File: ‘/usr/share/perl/5.20/strict.pm’
Size: 1006 Blocks: 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.000000000 +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.
>> 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.
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
>> 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.
>
[...]
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.
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
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
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.
Thanks again,
Kasper Loopstra.
gregor herrmann
Mar 29, 2015, 11:10:04 AM3/29/15
to
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
> 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
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?
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
Kasper Loopstra
Mar 29, 2015, 12:00:02 PM3/29/15
to
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.....
> 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$
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
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,
Niko Tyni
Mar 29, 2015, 2:10:04 PM3/29/15
to
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
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?
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
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
Kasper Loopstra
Mar 30, 2015, 1:20:03 AM3/30/15
to
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
> 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.
I'll try, but piecemeal upgrades are kind of difficult (I tried for
>> 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.
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.
0 new messages