Upgrading sa-compile to the version in stretch-proposed-updates fails with
| Setting up sa-compile (3.4.2-1~deb9u1) ...
| Running sa-compile (may take a long time)
| chmod: changing permissions of '/var/lib/spamassassin/compiled/5.024/3.004001/auto/Mail/SpamAssassin/CompiledRegexps/body_neg100/body_neg100.so': Operation not permitted
| dpkg: error processing package sa-compile (--configure):
|  subprocess installed post-installation script returned error exit status 1
| Errors were encountered while processing:
|  sa-compile

Cheers

This file is owned by root:root. After moving it away, installation succeeded.

The failing line of the postinst script is:

        # Fixup perms -- group and other should be able to
        # read and execute, but never write.  Works around
        # sa-compile's failure to obey umask.
        runuser -u debian-spamd -- \
                chmod -R go-w,go+rX /var/lib/spamassassin/compiled

Cheers

Control: tags -1 + moreinfo
Control: severity -1 normal

The file in question would have been generated with sa-compile. However,
sa-compile has been run as the debian-spamd user for a long time (at
least as far back as wheezy). The cron.daily script uses the following
invocation:

        env -i LANG="$LANG" PATH="$PATH" start-stop-daemon \
            --chuid debian-spamd:debian-spamd --start \
            --exec /usr/bin/sa-compile -- --quiet

So if there were any root-owned files in the compiled output, I don't
see how they could have been put there by the package.

It's possible that sa-compile had, at some point, been manually executed
as root, in which case this is #721648. If you're able to provide any
more info about where that file could have come from or whether
sa-compile had ever run as root on this system, that could help to more
clearly identify what happened.

noah

I don't recall executing sa-compile as root, but that could have happened of
course. The file in question is cruft from an older version sa-compile. So could
the scripts at least be fixed to ignore curft?

Also, would it be possible for sa-compile to remove year old cruft on upgrades?

Cheers

It may be reasonable to completely remove /var/lib/spamassassin/compiled
after we're determined that we need to run sa-compile, but before
actually doing so. If anybody thinks this would be a bad idea, please
say so.

Yes, /var/lib/spamassassin/compiled should be removed on package
upgrade. Starting with 3.4.2-2:
https://salsa.debian.org/debian/spamassassin/commit/2ba0392535e47a1db329131c584d08a92a5a6340