https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8198
Sidney Markowitz <sidney@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #16 from Sidney Markowitz <sidney@sidney.com> ---
Ok, I'm ready to close this. Here are the remaining test failures I see on CPAN
test machines that I am giving up on:
Some DNS network related issues on test machine(s) running FreeBSD 10.1. It may
be related to large UDP packets, or just flaky behavior with UDP packets under
heavy load. Whatever it is, I don't care about FreeBSD 10.1 and it doesn't seem
like a SpamAssassin issue that needs fixing.
One FreeBSD 14.0 test machine fails t/bayesdbm.t consistently. I can't
reproduce it on a FreeBSD 14.0 VM. I suspect that the test machine has a
mismatch between the version of BerkeleyDB that its perl is compiled with and
the version in the system's shared libraries. Or something like that. Not a
SpamAssassin bug.
DNS network issues on Windows test machines. Doesn't happen on my test VMs. I
just discovered that the OS name and version info displayed on the CPAN tests
reports are incorrect. They show the OS and version that perl was compiled
under, not the version running the program. For anything except Windows that is
likely to be close enough, but if a Windows user is running Strawberry Perl
5.X.Y it will show whatever version of Windows was used to build that version
of the installer when it was released at the time it was new. So all tests I
thought were being run on Windows 10 machines were actually old Windows
machines that had installed a recent version of Strawberry Perl. It turns out
that most of the Windows test machines on CPAN are running Windows 7, 8, or
8.1. We don't have to care if they exhibit sporadic flaky DNS network behavior
during our tests.
And those two or so machines running some flavor of Linux that have something
strange in their setup of tmp storage that causes all of our tests to fail with
an impossible taint error trying to create a temporary directory.
--
You are receiving this mail because:
You are the assignee for the bug.
Sidney Markowitz <sidney@sidney.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #16 from Sidney Markowitz <sidney@sidney.com> ---
Ok, I'm ready to close this. Here are the remaining test failures I see on CPAN
test machines that I am giving up on:
Some DNS network related issues on test machine(s) running FreeBSD 10.1. It may
be related to large UDP packets, or just flaky behavior with UDP packets under
heavy load. Whatever it is, I don't care about FreeBSD 10.1 and it doesn't seem
like a SpamAssassin issue that needs fixing.
One FreeBSD 14.0 test machine fails t/bayesdbm.t consistently. I can't
reproduce it on a FreeBSD 14.0 VM. I suspect that the test machine has a
mismatch between the version of BerkeleyDB that its perl is compiled with and
the version in the system's shared libraries. Or something like that. Not a
SpamAssassin bug.
DNS network issues on Windows test machines. Doesn't happen on my test VMs. I
just discovered that the OS name and version info displayed on the CPAN tests
reports are incorrect. They show the OS and version that perl was compiled
under, not the version running the program. For anything except Windows that is
likely to be close enough, but if a Windows user is running Strawberry Perl
5.X.Y it will show whatever version of Windows was used to build that version
of the installer when it was released at the time it was new. So all tests I
thought were being run on Windows 10 machines were actually old Windows
machines that had installed a recent version of Strawberry Perl. It turns out
that most of the Windows test machines on CPAN are running Windows 7, 8, or
8.1. We don't have to care if they exhibit sporadic flaky DNS network behavior
during our tests.
And those two or so machines running some flavor of Linux that have something
strange in their setup of tmp storage that causes all of our tests to fail with
an impossible taint error trying to create a temporary directory.
--
You are receiving this mail because:
You are the assignee for the bug.