You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2007/05/01 15:53:09 UTC
Re: 3.2.0 full release proposal
Doc Schneider writes:
> Justin Mason wrote:
> > Hey --
> >
> > 3.2.0-rc3 has gone very well -- pretty quiet in terms of bug reports. The
> > ones that are there, I think we can leave for a 3.2.1 fix release.
> > We're a bit behind schedule for 3.2.0 ;)
> >
> > Given this, I propose we issue a full release of 3.2.0 later this week
> > (Wednesday?) -- any objections?
> >
> > --j.
>
> I'd say +1 to a release. 8*) No troubles here with it. (After I fixed my
> own DNS issues).
cool, thanks for the vote Doc. That's one +1 and no objections ;)
I'll get making a tarball for some proper voting.
Reminder: here are the outstanding 3.2.0 bugs:
5379 spamd doesn't start if /tmp/spamd-$pid-init exists
5412 spamc -x -R always returns zero
5422 spamd error: 'prefork: ordered child N to accept, but they reported state '1', killing rogue'
5432 win32 build should default to not building spamc
5419 kill -HUP `pidof spamd` causes the ps name to change from "spamd" to "perl"
[no bug number?] Sidney's DNS-on-win32 issue? is this still a bug?
All are marked "deferable" -- by me at least ;) -- in other words I think
they can wait for 3.2.1. (we could spend forever trying to fix every
little bug for 3.2.0, better IMO to get the release out and clean up the
minor issues afterwards.)
The changes since 3.2.0-rc3 are a set of the usual "promotions validated",
a doc change (r532138 | sidney | 2007-04-24 23:37:02 +0000 (Tue, 24 Apr
2007) | 1 line: trivial doc change. Add -V --version to usage, man, and
pod), and a CREDITS change (r533729 | jm | 2007-04-30 12:47:59 +0000 (Mon,
30 Apr 2007) | 1 line: add Matt Kettler to the PMC; welcome Matt). No
impactful code changes.
--j.
Re: 3.2.0 full release proposal
Posted by Sidney Markowitz <si...@sidney.com>.
Doc Schneider wrote, On 2/5/07 7:47 AM:
> I was having this same problem and had to change my /etc/resolv.conf
> file to point the first nameserver to an actual server.
I've tried different nameservers there with no resolution. I think that
what I'm seeing is an effect of the strange latency and packet loss
characteristics of my satellite internet connection causing similar
results to having an underpowered router try to handle the DNS.
-- sidney
Re: 3.2.0 full release proposal
Posted by Doc Schneider <ma...@maddoc.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sidney Markowitz wrote:
> As another data point on the DNS thing, I just ran make test under MacOS
> on the proposed 3.2.0 release. As I have seen before, running it cold
> does result in t/dnsbl.t failures, then running it again (presumably
> with some DNS information in a cache) passes all tests. This is not the
> complete and consistent failures in both dnsbl and dnsbl_sc_meta I am
> seeing under Windows, but may be related.
>
> t/dnsbl..................... Not found: P_7 =
> <dns:134.88.73.210.sb.dnsbltest.spamassassin.org?type=TXT>
> t/dnsbl.....................ok 1/23# Failed test 2 in t/SATest.pm at
> line 633
> t/dnsbl.....................NOK 2/23 Not found: P_17 =
> DNSBL_SB_FLOAT
> # Failed test 9 in t/SATest.pm at line 633 fail #2
> Not found: P_18 = DNSBL_SB_STR
> # Failed test 10 in t/SATest.pm at line 633 fail #3
> Not found: P_16 = DNSBL_SB_TIME
> # Failed test 11 in t/SATest.pm at line 633 fail #4
> Output can be examined in: log/d.dns/1
> t/dnsbl.....................FAILED tests 2, 9-11
>
> Failed 4/23 tests, 82.61% okay
> t/dnsbl_sc_meta.............ok
>
> -- sidney
I was having this same problem and had to change my /etc/resolv.conf
file to point the first nameserver to an actual server. Mine was
pointing to my router for some reason. I think it had to do with one of
my NICs doing DHCP and not static.
Might want to check out that on your MAC OS X and see.
- -Doc
- --
-Doc
Penguins: Do it on the ice.
8:44am up 4 days, 16:55, 17 users, load average: 0.18, 0.30, 0.37
SARE HQ http://www.rulesemporium.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with CentOS - http://enigmail.mozdev.org
iD8DBQFGN5lNqOEeBwEpgcsRArz+AJ4o2gexDE+bHIHbOpvFdSnvRAcbggCePzIz
cUFTgOZo7n2a0vnWdsIWC+o=
=WJZx
-----END PGP SIGNATURE-----
Re: 3.2.0 full release proposal
Posted by Sidney Markowitz <si...@sidney.com>.
As another data point on the DNS thing, I just ran make test under MacOS
on the proposed 3.2.0 release. As I have seen before, running it cold
does result in t/dnsbl.t failures, then running it again (presumably
with some DNS information in a cache) passes all tests. This is not the
complete and consistent failures in both dnsbl and dnsbl_sc_meta I am
seeing under Windows, but may be related.
t/dnsbl..................... Not found: P_7 =
<dns:134.88.73.210.sb.dnsbltest.spamassassin.org?type=TXT>
t/dnsbl.....................ok 1/23# Failed test 2 in t/SATest.pm at
line 633
t/dnsbl.....................NOK 2/23 Not found: P_17 =
DNSBL_SB_FLOAT
# Failed test 9 in t/SATest.pm at line 633 fail #2
Not found: P_18 = DNSBL_SB_STR
# Failed test 10 in t/SATest.pm at line 633 fail #3
Not found: P_16 = DNSBL_SB_TIME
# Failed test 11 in t/SATest.pm at line 633 fail #4
Output can be examined in: log/d.dns/1
t/dnsbl.....................FAILED tests 2, 9-11
Failed 4/23 tests, 82.61% okay
t/dnsbl_sc_meta.............ok
-- sidney
Re: 3.2.0 full release proposal
Posted by Sidney Markowitz <si...@sidney.com>.
Justin Mason wrote, On 2/5/07 1:53 AM:
> [no bug number?] Sidney's DNS-on-win32 issue? is this still a bug?
My satellite internet connection went down completely and I couldn't
test more. Now that it's back I haven't had a chance to test again. The
last time IPSTAR had major downtime here when it came back I had similar
strange ongoing problems disappear, so I won't be surprised if my DNS
behaves better the next time I test.
I did decide that if other people on more reasonable connections don't
see the same DNS behavior than it isn't worth making a priority, and may
not even be worth calling a bug. I'll keep looking at this just because
it is a challenging problem.
Oh, by the way, I don't think that the hard coded "20" in the async code
is a problem. For it to trigger an abort there has to be 20 seconds
during which there are no DNS replies coming in at all. The flakiness
that I am seeing results in all DNS replies being lost after the first N
queries, but I've never seen straggler replies showing up that long
after the previous reply and there are always some replies coming back
sooner than 20 seconds. If someone has a setup in which it takes more
than 20 seconds to get any DNS query answered than they probably do not
want to be running network tests in the first place.
-- sidney