You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by "Kevin A. McGrail" <KM...@PCCC.com> on 2011/05/16 23:59:28 UTC
SA 3.3.2 Release Candidate 1 call for testing & comments
On 5/16/2011 5:22 PM, Warren Togami Jr. wrote:
> PMC? Committers? No testing and votes?
>
> Warren
I'm running it now on a production system and things in general look good.
But the rc1 for me is a likely a no vote until we get a rules tarball
that can actually be distributed.
I also think bug 6588 as silly and small as it is should be included in
3.3.2's release.
Other than that, I would have voted +1.
However, I am using sa-update's rules version 1083704. What are your
thoughts on including 1083704.tar.gz as the rules tarball for 3.3.2
since sa-update is our focus and a rule tarball is just kind of a base
install moreso than the intended method of running SA?
Can anyone upload the rc1 as a an underscore release on cpan so we can
confirm it compiles on a bunch of boxes? Also, if anyone has a
production 5.12.X system that was throwing all the errors, would be nice
to have them weigh in on the release too.
Regards,
KAM
revert-stable-update (was Re: SA 3.3.2 Release Candidate 1 call for
testing & comments)
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 17/05/2011 11:10 PM, Daryl C. W. O'Shea wrote:
> I plan to write a script to handle reverting to a known good update in
> an emergency before I re-enable the updates. The script will need to be
> run as updatesd on the Solaris zone and will have syntax something like:
>
> ./revert-stable-update 1083704
This is now done. The syntax is as above.
> Usage details will follow when its ready. The script will:
Usage details are in the top of the script file. It's easy:
1) login to spamassassin.zones.apache.org
2) sudo su - updatesd
3) /home/updatesd/svn/mkupdates-with-scores/revert-stable-update 1234567
> - accept an update number (that will be on the update mirrors already)
> - test the given update against the stable versions of SA
> - update DNS immediately
> - *maybe* automatically halt future automatic update generation
DNS actually waits 16 minutes to update (just like for a normal update)
to give the mirros that sync every 15 minutes time to sync up. The
update is run via the at queue.
The script *DOES* create the file
rulesrc/scores/DISABLE-AUTOMATIC-UPDATES to signal the auto-update
script build/mkupdates/mkupdate-with-scores to not update the update
version info in DNS when run to generate a new update package. The file
is created whenever you run the revert-stable-update script to do a
reversion. To re-enable auto-update publishing simply delete the file
from SVN.
Daryl
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
Thanks, daryl!
Regards,
KAM
"Daryl C. W. O'Shea" <sp...@dostech.ca> wrote:
On 16/05/2011 10:30 PM, Warren Togami Jr. wrote: > On 5/16/2011 4:26 PM, Daryl C. W. O'Shea wrote: >> On 16/05/2011 5:59 PM, Kevin A. McGrail wrote: >>> However, I am using sa-update's rules version 1083704. What are your >>> thoughts on including 1083704.tar.gz as the rules tarball for 3.3.2 >>> since sa-update is our focus and a rule tarball is just kind of a base >>> install moreso than the intended method of running SA? >> >> That would be the correct thing to do, that is use the latest 3.3.x >> update. >> >> I would imagine that there will be new updates, too, in the next couple >> of days. I'm just going through old email and bugs trying to figure out >> if there are any other issues that need resolving before turning it back >> on. >> >> Daryl > > Could we please have the unpublished candidate for the next rules > tarball posted for review before it goes live? Update 1104058 on the update mirrors. No real changes... the last round of issues were rules that triggered c!
ode
issues -- unavoidable, I think. I've made one important improvement. Scores in the sandboxes are now used to set the absolute maximum rule score (positive or negative). Evolved scores may be less than the score value in the sandbox but should not exceed it. I plan to write a script to handle reverting to a known good update in an emergency before I re-enable the updates. The script will need to be run as updatesd on the Solaris zone and will have syntax something like: ./revert-stable-update 1083704 Usage details will follow when its ready. The script will: - accept an update number (that will be on the update mirrors already) - test the given update against the stable versions of SA - update DNS immediately - *maybe* automatically halt future automatic update generation Daryl
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
Not known to me. Can you open a ticket please and enable verbose tests?
Regards,
KAM
Sidney Markowitz <si...@sidney.com> wrote:
Is this a known issue or non-issue? On my macbook in make test I'm getting t/trust_path.t .................... 49/96 # Failed test 69 in t/trust_path.t at line 694 fail #23 # Failed test 72 in t/trust_path.t at line 694 fail #24 # Failed test 75 in t/trust_path.t at line 694 fail #25 # Failed test 78 in t/trust_path.t at line 694 fail #26
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
Bug tickets please. These are 3.3.2 blockers for sure but it's good to find out about them.
Regards,
KAM
Sidney Markowitz <si...@sidney.com> wrote:
I enabled run_sql_pref_tests and this time I also got a failure in test 14 of t/spamd_sql_prefs.t I ran the same make test on a Fedora 14 box and got the same failed tests, trust_path.t tests 69, 72, 75 and 78; and spamd_sql_prefs.t test 14. In case the local network configuration might have something to do with it, yes, the macbook and the Fedora 14 box are on the same subnet behind the same NAT. I'm running perl 5.12.3 on both the Mac and Fedora. The Mac is 32 bit and Fedora is 64 bit. Sidney
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by Sidney Markowitz <si...@sidney.com>.
I enabled run_sql_pref_tests and this time I also got a failure in test 14 of
t/spamd_sql_prefs.t
I ran the same make test on a Fedora 14 box and got the same failed tests,
trust_path.t tests 69, 72, 75 and 78; and spamd_sql_prefs.t test 14.
In case the local network configuration might have something to do with it,
yes, the macbook and the Fedora 14 box are on the same subnet behind the same NAT.
I'm running perl 5.12.3 on both the Mac and Fedora. The Mac is 32 bit and
Fedora is 64 bit.
Sidney
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by Sidney Markowitz <si...@sidney.com>.
Is this a known issue or non-issue?
On my macbook in make test I'm getting
t/trust_path.t .................... 49/96
# Failed test 69 in t/trust_path.t at line 694 fail #23
# Failed test 72 in t/trust_path.t at line 694 fail #24
# Failed test 75 in t/trust_path.t at line 694 fail #25
# Failed test 78 in t/trust_path.t at line 694 fail #26
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 5/24/2011 5:58 AM, Warren Togami Jr. wrote:
> On 5/18/2011 4:38 PM, Daryl C. W. O'Shea wrote:
>>
>> Pick a mirror from the MIRRORED.BY file and download the three files
>> associated with the update revision number noted.
>>
>> wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz
>> wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz.asc
>> wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz.sha1
>>
>> Daryl
>
> I manually inspected it and ran it for the past few days, seemingly
> without issue. I suppose it would be a good idea to push it live and
> enable automatic updates now.
>
+1 here. I am also running it on a production system.
Continue to work through mostly tiny issues with 3.3.2 from that work.
regards,
KAM
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 5/18/2011 4:38 PM, Daryl C. W. O'Shea wrote:
>
> Pick a mirror from the MIRRORED.BY file and download the three files
> associated with the update revision number noted.
>
> wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz
> wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz.asc
> wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz.sha1
>
> Daryl
I manually inspected it and ran it for the past few days, seemingly
without issue. I suppose it would be a good idea to push it live and
enable automatic updates now.
Warren
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 18/05/2011 10:32 PM, Warren Togami Jr. wrote:
> On 5/18/2011 3:58 PM, Daryl C. W. O'Shea wrote:
>> I'm hoping you're already testing with the update you requested that you
>> get to test with before publishing the update in DNS.
>>
>> Update 1104058 that is available on the sa-update mirrors (just download
>> the three files with wget or something) can be used as your release rule
>> tarball if you're happy with it. This update is generated just as an
>> update would be if it were published in DNS, the only difference is I
>> didn't let the script update DNS.
>>
>> Daryl
>>
>
> Sorry, it is not clear how to look at files available on the sa-update
> mirrors. Could you please explicitly spell it out?
Pick a mirror from the MIRRORED.BY file and download the three files
associated with the update revision number noted.
wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz
wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz.asc
wget http://daryl.dostech.ca/sa-update/asf/1104058.tar.gz.sha1
Daryl
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 5/18/2011 3:58 PM, Daryl C. W. O'Shea wrote:
> I'm hoping you're already testing with the update you requested that you
> get to test with before publishing the update in DNS.
>
> Update 1104058 that is available on the sa-update mirrors (just download
> the three files with wget or something) can be used as your release rule
> tarball if you're happy with it. This update is generated just as an
> update would be if it were published in DNS, the only difference is I
> didn't let the script update DNS.
>
> Daryl
>
Sorry, it is not clear how to look at files available on the sa-update
mirrors. Could you please explicitly spell it out?
Warren
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 18/05/2011 8:43 AM, Warren Togami Jr. wrote:
> On 5/18/2011 2:27 AM, Kevin A. McGrail wrote:
>>
>>
>>> How about we wait until we have the update system working again and
>>> we're happy with a newly generated rules tarball. At that point we cut
>>>
>>> 3.3.2-rc2 for more testing.
>>
>> The code works with existing rules and sa-update is designed to
>> separate the rules from code. I am negative on waiting for a release
>> just because rules as long as we have a working tar we can release
>> that is reasonably recent.
>
> That's fine by me, if we have enough substantive changes since "rc1"
> that we need wider testing for another code cut, then we'll do it.
>
> Otherwise I think it would be worthwhile to have a (subsequent?) cut
> specifically so many people to test it with the actual rule update
> tarball. Given that rule update generation has been broken for so long,
> there is still the potential for surprises if we change both the code
> and rules at the same time without testing them together.
I'm hoping you're already testing with the update you requested that you
get to test with before publishing the update in DNS.
Update 1104058 that is available on the sa-update mirrors (just download
the three files with wget or something) can be used as your release rule
tarball if you're happy with it. This update is generated just as an
update would be if it were published in DNS, the only difference is I
didn't let the script update DNS.
Daryl
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 5/18/2011 2:27 AM, Kevin A. McGrail wrote:
>
>
>> How about we wait until we have the update system working again and
>> we're happy with a newly generated rules tarball. At that point we cut
>>
>> 3.3.2-rc2 for more testing.
>
> The code works with existing rules and sa-update is designed to separate the rules from code. I am negative on waiting for a release just because rules as long as we have a working tar we can release that is reasonably recent.
That's fine by me, if we have enough substantive changes since "rc1"
that we need wider testing for another code cut, then we'll do it.
Otherwise I think it would be worthwhile to have a (subsequent?) cut
specifically so many people to test it with the actual rule update
tarball. Given that rule update generation has been broken for so long,
there is still the potential for surprises if we change both the code
and rules at the same time without testing them together.
>
>> PLEASE allow it to be policy to never reuse a version name and number
>> ever again. Numbers are cheap. We can use as many as we want.
>>
>> Furthermore, I hope that we can have a final rc which is really meant
>> to
>> be a release candidate. If we vote to release that, then it gets recut
>>
>> as the actual 3.3.2 with zero code changes. This completely eliminates
>>
>> our confusing past practice of reusing numbers like last year's "Oops,
>> this is the real 3.3.1, not that previous tarball of the same name!"
>
> I am 100% behind this. There was consensus to create the rc1 and rc1 was released. At worst the next versions must be rc1-build2.
I think CPAN, rpm and deb's version comparison algorithms wouldn't take
too kindly to a dash in the version field. rpm I know uses a dash as a
field separator, and dash is forbidden in versions and subversions.
Just declare "rc1" dead and declare the next cut "rc2".
Warren
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
>How about we wait until we have the update system working again and
>we're happy with a newly generated rules tarball. At that point we cut
>
>3.3.2-rc2 for more testing.
The code works with existing rules and sa-update is designed to separate the rules from code. I am negative on waiting for a release just because rules as long as we have a working tar we can release that is reasonably recent.
>PLEASE allow it to be policy to never reuse a version name and number
>ever again. Numbers are cheap. We can use as many as we want.
>
>Furthermore, I hope that we can have a final rc which is really meant
>to
>be a release candidate. If we vote to release that, then it gets recut
>
>as the actual 3.3.2 with zero code changes. This completely eliminates
>
>our confusing past practice of reusing numbers like last year's "Oops,
>this is the real 3.3.1, not that previous tarball of the same name!"
I am 100% behind this. There was consensus to create the rc1 and rc1 was released. At worst the next versions must be rc1-build2.
Regards,KAM
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 18/05/2011 8:13 AM, Warren Togami Jr. wrote:
> On 5/17/2011 5:10 PM, Daryl C. W. O'Shea wrote:
>>
>> Update 1104058 on the update mirrors.
>>
>> No real changes... the last round of issues were rules that triggered
>> code issues -- unavoidable, I think.
>>
>> I've made one important improvement. Scores in the sandboxes are now
>> used to set the absolute maximum rule score (positive or negative).
>> Evolved scores may be less than the score value in the sandbox but
>> should not exceed it.
>>
>> I plan to write a script to handle reverting to a known good update in
>> an emergency before I re-enable the updates. The script will need to be
>> run as updatesd on the Solaris zone and will have syntax something like:
>>
>> ./revert-stable-update 1083704
>>
>> Usage details will follow when its ready. The script will:
>>
>> - accept an update number (that will be on the update mirrors already)
>> - test the given update against the stable versions of SA
>> - update DNS immediately
>> - *maybe* automatically halt future automatic update generation
>>
>> Daryl
>
> How about we wait until we have the update system working again and
> we're happy with a newly generated rules tarball. At that point we cut
> 3.3.2-rc2 for more testing.
Is there something else I need to fix before everyone's happy with the
rule updates going live? Other than the above mentioned script to do
the emergency update reversion (which won't have any affect on *how*
updates are generated, but maybe *if* they are generated).
Daryl
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 5/17/2011 5:10 PM, Daryl C. W. O'Shea wrote:
>
> Update 1104058 on the update mirrors.
>
> No real changes... the last round of issues were rules that triggered
> code issues -- unavoidable, I think.
>
> I've made one important improvement. Scores in the sandboxes are now
> used to set the absolute maximum rule score (positive or negative).
> Evolved scores may be less than the score value in the sandbox but
> should not exceed it.
>
> I plan to write a script to handle reverting to a known good update in
> an emergency before I re-enable the updates. The script will need to be
> run as updatesd on the Solaris zone and will have syntax something like:
>
> ./revert-stable-update 1083704
>
> Usage details will follow when its ready. The script will:
>
> - accept an update number (that will be on the update mirrors already)
> - test the given update against the stable versions of SA
> - update DNS immediately
> - *maybe* automatically halt future automatic update generation
>
> Daryl
How about we wait until we have the update system working again and
we're happy with a newly generated rules tarball. At that point we cut
3.3.2-rc2 for more testing.
And before someone brings it up:
I know someone will want to reuse the "rc1" label since we never voted
on its release. But by the time we're ready for the next cut, it would
have already been a week or more with something called "rc1" in the wild
and it would simply be TOO CONFUSING to folks to reuse the tag. There
are over 210 people running my 3.3.2-rc1 test RPMS at the moment. I
don't want to confuse them with another "rc1".
PLEASE allow it to be policy to never reuse a version name and number
ever again. Numbers are cheap. We can use as many as we want.
Furthermore, I hope that we can have a final rc which is really meant to
be a release candidate. If we vote to release that, then it gets recut
as the actual 3.3.2 with zero code changes. This completely eliminates
our confusing past practice of reusing numbers like last year's "Oops,
this is the real 3.3.1, not that previous tarball of the same name!"
Warren Togami
warren@togami.com
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 16/05/2011 10:30 PM, Warren Togami Jr. wrote:
> On 5/16/2011 4:26 PM, Daryl C. W. O'Shea wrote:
>> On 16/05/2011 5:59 PM, Kevin A. McGrail wrote:
>>> However, I am using sa-update's rules version 1083704. What are your
>>> thoughts on including 1083704.tar.gz as the rules tarball for 3.3.2
>>> since sa-update is our focus and a rule tarball is just kind of a base
>>> install moreso than the intended method of running SA?
>>
>> That would be the correct thing to do, that is use the latest 3.3.x
>> update.
>>
>> I would imagine that there will be new updates, too, in the next couple
>> of days. I'm just going through old email and bugs trying to figure out
>> if there are any other issues that need resolving before turning it back
>> on.
>>
>> Daryl
>
> Could we please have the unpublished candidate for the next rules
> tarball posted for review before it goes live?
Update 1104058 on the update mirrors.
No real changes... the last round of issues were rules that triggered
code issues -- unavoidable, I think.
I've made one important improvement. Scores in the sandboxes are now
used to set the absolute maximum rule score (positive or negative).
Evolved scores may be less than the score value in the sandbox but
should not exceed it.
I plan to write a script to handle reverting to a known good update in
an emergency before I re-enable the updates. The script will need to be
run as updatesd on the Solaris zone and will have syntax something like:
./revert-stable-update 1083704
Usage details will follow when its ready. The script will:
- accept an update number (that will be on the update mirrors already)
- test the given update against the stable versions of SA
- update DNS immediately
- *maybe* automatically halt future automatic update generation
Daryl
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Warren Togami Jr." <wt...@gmail.com>.
On 5/16/2011 4:26 PM, Daryl C. W. O'Shea wrote:
> On 16/05/2011 5:59 PM, Kevin A. McGrail wrote:
>> However, I am using sa-update's rules version 1083704. What are your
>> thoughts on including 1083704.tar.gz as the rules tarball for 3.3.2
>> since sa-update is our focus and a rule tarball is just kind of a base
>> install moreso than the intended method of running SA?
>
> That would be the correct thing to do, that is use the latest 3.3.x update.
>
> I would imagine that there will be new updates, too, in the next couple
> of days. I'm just going through old email and bugs trying to figure out
> if there are any other issues that need resolving before turning it back
> on.
>
> Daryl
Could we please have the unpublished candidate for the next rules
tarball posted for review before it goes live?
Warren
Re: SA 3.3.2 Release Candidate 1 call for testing & comments
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 16/05/2011 5:59 PM, Kevin A. McGrail wrote:
> However, I am using sa-update's rules version 1083704. What are your
> thoughts on including 1083704.tar.gz as the rules tarball for 3.3.2
> since sa-update is our focus and a rule tarball is just kind of a base
> install moreso than the intended method of running SA?
That would be the correct thing to do, that is use the latest 3.3.x update.
I would imagine that there will be new updates, too, in the next couple
of days. I'm just going through old email and bugs trying to figure out
if there are any other issues that need resolving before turning it back on.
Daryl