SA Bugzilla – Bug 7005
sa_compile.t test failures with MacPorts' perl
Last modified: 2022-03-06 12:54:42 UTC
MacPorts perl sets sitebin to ${prefix}/libexec/${perlversion}/sitebin [current default is /opt/local/libexec/perl5.12/sitebin], which causes sa_compile.t to not be able to find spamassasin and sa-compile. I manually modified sa_compile.t for my local installation and verified that the tests pass. While I personally don't like MacPorts' approach here, the test should probably handle this situation. I can probably provide a patch that uses Config to pull the appropriate path info, if desired (it should be fairly trivial to add $Config{sitebinexp}).
Good to know the tests pass, thanks. If you can help with a patch, that would be great.
Created attachment 5184 [details] use Config to get path when non-standard sitebin is set This works for me (but obviously should get some review from at least people with more 'normal' perl installs).
> Created attachment 5184 [details] > use Config to get path when non-standard sitebin is set > This works for me (but obviously should get some review from at least people > with more 'normal' perl installs). Sounds like a plan. The s/// at line 10 should better take the $Config{prefix} literally (i.e. quoted): s{^\Q$Config{prefix}\E/?}{}
Patch is pretty trivial and looks good to me. svn commit -m 'Patch from Daniel J. Luke to use Config to get path when non-standard sitebin is set' Sending t/sa_compile.t Transmitting file data . Committed revision 1570329..
Bug 7005: sa_compile.t test failures with MacPorts' perl - safe quoting Sending t/sa_compile.t Committed revision 1570334.
See bug 7181. This patch breaks prove -v t/sa_compile.t on source install of SA 3.4.1 on a Debian 7.4 box. Daniel, any thoughts on this?
I think the problem is/was with more than one directory. Running 'port -d test p5.16-mail-spamassassin' with 3.4.0 fails in t/sa_compile.t with this: [...] a Mail-SpamAssassin-3.4.0/build/parse-rules-for-masses a Mail-SpamAssassin-3.4.0/build/preprocessor a Mail-SpamAssassin-3.4.0/build/sha1sum.pl cannot write /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-mail-spamassassin/p5.16-mail-spamassassin/work/Mail-SpamAssassin-3.4.0/t/log/d.sa_compile/inst.basic/foo/etc/mail/spamassassin/v330.pre at t/sa_compile.t line 85. t/sa_compile.t .................... Dubious, test returned 2 (wstat 512, 0x200) Failed 5/5 subtests While the same command after cleaning & updating the Portfile to fetch and build 3.4.1 yields this: [...] a Mail-SpamAssassin-3.4.1/build/parse-rules-for-masses a Mail-SpamAssassin-3.4.1/build/preprocessor a Mail-SpamAssassin-3.4.1/build/sha1sum.pl sa-compile: cannot write to /var/opt/spamassassin/compiled/5.016/3.004001, aborting '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-mail-spamassassin/p5.16-mail-spamassassin/work/Mail-SpamAssassin-3.4.1/t/log/d.sa_compile/inst.basic/foo//libexec/perl5.16/sitebin/sa-compile --keep-tmps' failed: exit 2 at t/SATest.pm line 991. t/sa_compile.t .................... Dubious, test returned 2 (wstat 512, 0x200) Failed 3/5 subtests Note that 3.4.1 apparently gets further (2 tests passed) and is for some reason trying to write in /var/opt/spamassassin, *WHICH SHOULDN'T EXIST* If you actually use MacPorts to install either version -- both of which do work -- the fact that MacPorts sets LOCALSTATEDIR=/opt/local/var/spamassassin to build the Makefile means that you get: # ls -l /opt/local/var/spamassassin/ total 0 drwxr-xr-x 3 root admin 136 Jul 13 2014 3.003002 drwxr-xr-x 3 root admin 136 Apr 23 12:49 3.004000 drwxr-xr-x 3 root admin 136 May 1 18:55 3.004001 drwxr-xr-x 3 root admin 102 May 1 23:35 compiled But this hint isn't making it to the test rig. The "MakeMaker ARGV" line in the Makefile created in sa_compile.t is a smoking gun. In short: replace line 129 of t/sa_compile.t with something that doesn't assume PREFIX is the only directory anyone will customize.
(In reply to Kevin A. McGrail from comment #6) > See bug 7181. This patch breaks prove -v t/sa_compile.t on source install > of SA 3.4.1 on a Debian 7.4 box. > > Daniel, any thoughts on this? Note that I don't use MacPorts perl anymore (or have a debian box around to test with), but looking at what sitebin is set to on a box where the test(s) are failing would probably be interesting.
(In reply to Bill Cole from comment #7) > In short: replace line 129 of t/sa_compile.t with something that doesn't > assume PREFIX is the only directory anyone will customize. I think you may have hit on something real (but probably shouldn't be in this bug report). Also, some/most of this can (and maybe should) be addressed in the MacPorts port (ie, even if the directory in the final error you posted was 'correct', MacPorts would still not be able to write in that directory as the test phase doesn't run as root by default).
OK, so I guess I should rephrase that more directly and less verbosely: The test file t/sa_compile.t configures a complete build & installation of SA from scratch with a directory configuration that entirely ignores any installation directives of the build supposedly being tested other than a custom PREFIX. This is not a MacPorts issue. This is a logical problem with the test design, which explicitly avoids testing with 'make test' the SA build that 'make install' will in fact install. Bluntly: it's a test that tests itself and can't even pass that.
(In reply to Bill Cole from comment #10) > This is not a MacPorts issue. This is a logical problem with the test > design, which explicitly avoids testing with 'make test' the SA build that > 'make install' will in fact install. Bluntly: it's a test that tests itself > and can't even pass that. so you chose to mention this in an old bug about using sitebin in the test? This isn't my bug tracker, but I would think it would be better for you to open a new bug (and maybe include a patch if possible).
(In reply to Daniel J. Luke from comment #11) > so you chose to mention this in an old bug about using sitebin in the test? I admit to being excessively influenced by Kevin re-opening this ticket and by the fact that with the patch, both 3.4.0 and 3.4.1 fail in t/sa_compile.t if $prefix starts with /opt (as for MacPorts) unless /etc/opt and /var/opt are creatable by or exist and are writable by the user running the test. > This isn't my bug tracker, but I would think it would be better for you to > open a new bug (and maybe include a patch if possible). Done: Bug 7188
(In reply to Bill Cole from comment #12) > I admit to being excessively influenced by Kevin re-opening this ticket and > by the fact that with the patch, both 3.4.0 and 3.4.1 fail in t/sa_compile.t > if $prefix starts with /opt (as for MacPorts) unless /etc/opt and /var/opt > are creatable by or exist and are writable by the user running the test. submitting a patch is a good way to get me to forgive most transgressions ;-) Bill, can you look at submitting a CLA? http://www.apache.org/licenses/
Minor issue targeting for 3.4.3
Closing stale bug, reopen if it's still an issue.