On 11/11/2017 11:09 AM, Merijn van den Kroonenberg wrote:
On 11/11/2017 07:45 AM, Merijn van den Kroonenberg wrote:
I saw you applied my patch for ruleqa.cgi and if I read the apache conf
correctly, then the webserver serves pages directly from the checkout
/usr/local/spamassassin/automc/svn/masses/rule-qa/automc/ruleqa.cgi
Damn stupid me.
As I explained above the webserver serves directly from
/usr/local/spamassassin/automc/svn/masses/rule-qa/automc/ruleqa.cgi
Thats the *svn/masses* !
I am so glad you are helping and able to keep this stuff straight. I
worked on this stuff a lot back in the summer and have forgotten a lot
of what I did. :) I meant to have a cron job setup for the automc user
to do an "svn up ~/svn/masses" but it wasn't there until a few minutes
ago. I had patched the ruleqa.cgi and committed it but the "svn up
~/svn/masses" was needed. I just did this part so it's now active.
Sorry about that.
So the change should have gone live immediately if you applied the patch
directly in svn/trunk/masses (and not in svn/masses).
Thats the wrong way around! Actually for the change to go live it should
be patched in
/usr/local/spamassassin/automc/svn/masses/rule-qa/automc/ruleqa.cgi
But thats in the readonly working copy. I just verified in the resync
account and indeed the ruleqa.cgi has not been patched so my change did
NOT go live.
It should be live now. I manually verified the file at that path.
http://ruleqa.spamassassin.org/?longdatelist=1
So far good news on my latest patch to the SVN REVISION detection to
find the majority REVISION instead of the latetest REVISION.
llanga does stand out as being off a bit. It seems to be a day behind
at least by the date stamp. Do I need to put in a temporary cleanup for
this masschecker to toss it out?
But it seems the patch had not the hoped for effect so I guess I have to
keep looking then ;)
Please keep in this change for now.
Ok
On 11/10/2017 05:00 AM, Merijn van den Kroonenberg wrote:
I need some help understanding this problem now. The "promotions
validated" have failed for 3 weeks now so the active.list is not
updating. There seems to be some relationship to the masscheck
ruleqa
web output that is stuck on "day 2" failing. See the output at the
very
bottom.
I am trying to see whats going on. I would really like some insight in
the
file:
/usr/local/spamassassin/automc/html/ruleqa.cache
And i would like to have some insight into which masscheck results are
present on disk. So the output of something like this:
ls -la /usr/local/spamassassin/automc/html/2017*
ls -la /usr/local/spamassassin/automc/html/20171*/*
or something which gives me a tree view.
Can someone look at the perl script "listpromotable" and figure out
what
is going on? I can tell it's looking at the output by day to find
"mcviewing" and "mcsubmitters".
Would you say:
http://ruleqa.spamassassin.org/?longdatelist=1
those are really all masschecks? This seems unlikely to me, I would
expect
to see masschecks with many contributors much more often (every day?)
This is day 1 match which is green when you view it in a browser:
<td class="daterevtd mcviewing" width='20%'>
<span class="daterev_masscheck_description mcviewing">
<p>
<a name="r20171106_r1814390_n"
href="/20171106-r1814390-n?xml=1"><strong>
<span class="dr">20171106-r1814390-n</span>
</strong></a> <b>(Viewing)</b>
</p><p>
<em><span class="mcsubmitters">axb-coi-bulk axb-generic
axb-ham-misc darxus ena-week0 ena-week1 ena-week2 ena-week3 giovanni
jarif jbrooks llanga mmiroslaw-mails-ham mmiroslaw-mails-spam
thendrikx</span></em>
</x>
</p>
Day 2 doesn't have that table with "mcviewing". The next question is
what is causing this problem. Is it related to new commits that
throw
off the masscheck processing?
The 2 days ago doesn't highlight a current masscheck....but still it
shows
a result at the bottom...so its showing *something*. I think its
likely
it
is the masxcheck as present in the datrev input field:
20171108-r1814560-n
But that one isn't in any daterev liting, not even in the full
listing.
So i think something in the ruleqa.cgi which builds the daterev list
is
broken and leaves out some masschecks.
If I get the cachefile and the ddirectory listings I can go debug
where
things go pear-shaped.
