I'm not talking about "your" bugs, I think they were fixed long time ago? There's been bunch of commits recently like OLEMacro plgin etc that isn't even enabled by default. Yea we are supposed to be RTC but even I don't care about it anymore, release was supposed to be done half a year ago or something. The project simply doesn't have enough active management and committers, so I guess we just go with the flow. :-)
On Thu, Nov 28, 2019 at 06:43:25AM -0500, Kevin A. McGrail wrote: > Many distros like to backport so I am not worried about that issue. > > I don't like bugs :-). And 3.4.3 needed the RCs to work for my system so it > made sense to fix the bugs. But it makes no sense for me to spend time > packaging them for so little feedback. > > On Thu, Nov 28, 2019, 06:40 Henrik K <[1]h...@hege.li> wrote: > > > Bugs like these aren't serious, probably even not worth postponing a > release, all that matters is that basic functionality works, we should > make > no guarantees for stuff like using strange tags in AskDNS rules. It's not > end of the world if we have to release 3.4.4 anyway. I wonder if > distributions even adopt 3.4.3.. > > On Thu, Nov 28, 2019 at 06:24:55AM -0500, Kevin A. McGrail wrote: > > The extreme lack of testing has had me worried as I have consistently > found > > bugs in the release. I think we failed a bit in the test driven > development > > and the ability to release fast and often is hurt by it. I really wanted > to > > close out 3.4 and move on to 4.0! > > > > With the current rc, I now have all the new functionality on a > production > > system and working but I have a grand total of about 3 emails from ALL > the RCs > > from testing. I am very nervous! > > > > On Thu, Nov 28, 2019, 06:19 Henrik K <[1][2]h...@hege.li> wrote: > > > > > > Sure why not.. should try actually releasing after that, before we > make a > > world record in rc-count. :-D > > > > On Thu, Nov 28, 2019 at 06:11:51AM -0500, Kevin A. McGrail wrote: > > > Fair enough. Ok to move forward with another rc do.you think? > > > > > > On Thu, Nov 28, 2019, 05:40 Henrik K <[1][2][3]h...@hege.li> > wrote: > > > > > > > > > It's not that the issue itself needs a test. AskDNS and/or > tag > > handling > > > currently have no tests at all. In addition there's some open > bugs > > looking > > > at the ways to use AskDNS and it's shortcomings (empty tags, > meta > > tests > > > breaking on askdns etc). TLDR: It actually requires a lot of > work, > > don't > > > have time or stamina right now. > > > > > > On Thu, Nov 28, 2019 at 05:33:03AM -0500, Kevin A. McGrail > wrote: > > > > I never would have found that.á Nice job. > > > > > > > > Any chance you can create a regression test for the issue ? > > > > > > > > On Thu, Nov 28, 2019, 05:09 Henrik K <[1][2][3][4] > h...@hege.li> wrote: > > > > > > > > > > > > Fixed: > > > > [2][3][4][5]http://svn.apache.org/viewvc?view=revision&; > revision= > > 1870552 > > > > > > > > On Thu, Nov 28, 2019 at 11:29:19AM +0200, Henrik K > wrote: > > > > > > > > > > Trunk has already many revamps and fixes for these > codes, > > works > > > there.á > > > > It > > > > > seems 3.4 askdns has trouble using those, > investigating > > minimal > > > fix.. > > > > > > > > > > > > > > > On Thu, Nov 28, 2019 at 10:20:39AM +0100, Tobi <[3][4] > > > [5][6]jahli...@gmx.ch> > > > > wrote: > > > > > > Henrik > > > > > > > > > > > > But my current testing clearly shows that without > the > > explicit > > > set_tag > > > > > > _LASTEXTERNALRDNS_ and _LASTEXTERNALHELO_ won't be > set. > > > > > > I'm testing this using spamassassin in debug mode to > scan a > > > > testmessage. > > > > > > As soon as I re-add the set_tag to PerMsgStatus.pm > the tags > > are > > > set and > > > > > > tests based on that tags are run. Removing the lines > from > > pm and > > > debug > > > > > > shows that the tests are **not** run anymore. > > > > > > > > > > > > So I somewhat doubt that the set_tag "code is > redundant and > > > should be > > > > > > removed" :-) > > > > > > > > > > > > Using: SA 3.4.2 on centos7 / perl 5.16.3 > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > > > > tobi > > > > > > > > > > > > Am 28.11.19 um 08:36 schrieb Henrik K: > > > > > > > > > > > > > > There is nothing missing.á All the LASTEXT* tags > are > > already > > > > dynamically > > > > > > > returning functions.á If anything, that if > ($lasthop) > > set_tag > > > code is > > > > > > > completely redundant and should be removed. > > > > > > > > > > > > > > > > > > > > > BEGIN { > > > > > > >á á áLASTEXTERNALIP => sub { > > > > > > >á á á ámy $pms = shift; > > > > > > >á á á ámy $lasthop = $pms->{relays_external}->[0]; > > > > > > >á á á á$lasthop ? $lasthop->{ip} : ''; > > > > > > >á á á}, > > > > > > > > > > > > > >á á áLASTEXTERNALRDNS => sub { > > > > > > >á á á ámy $pms = shift; > > > > > > >á á á ámy $lasthop = $pms->{relays_external}->[0]; > > > > > > >á á á á$lasthop ? $lasthop->{rdns} : ''; > > > > > > >á á á}, > > > > > > > > > > > > > >á á áLASTEXTERNALHELO => sub { > > > > > > >á á á ámy $pms = shift; > > > > > > >á á á ámy $lasthop = $pms->{relays_external}->[0]; > > > > > > >á á á á$lasthop ? $lasthop->{helo} : ''; > > > > > > >á á á}, > > > > > > > > > > > > > > > > > > > > > On Wed, Nov 27, 2019 at 10:18:20AM -0500, Kevin A. > > McGrail > > > wrote: > > > > > > >> After a 10 minute or so study of the issue and > comparing > > 3.4 > > > and > > > > trunk, > > > > > > >> it definitely looks like the code is missing.á I > am not > > 100% > > > sure > > > > your > > > > > > >> fix works but it's better than it currently > exists > :-) > > > > > > >> > > > > > > >> Have you been using that change in production? > > > > > > >> > > > > > > >> Regards, > > > > > > >> > > > > > > >> KAM > > > > > > >> > > > > > > >> On 11/27/2019 6:59 AM, Tobi <[4][5][6][7] > jahli...@gmx.ch> > > wrote: > > > > > > >>> Hi, > > > > > > >>> > > > > > > >>> is there any specific reason why the two tags > mentioned > > in > > > subject > > > > are > > > > > > >>> not set in SA? It took me a while to find out > why > an > > askdns > > > test > > > > was not > > > > > > >>> running. The test relies on _LASTEXTERNALRDNS_ > but > > after > > > running > > > > with > > > > > > >>> --debug I found that those tags are not set by > SA. > > Although > > > > > > >>> _LASTEXTERNALIP_ is set. Also the man page > states > that > > the > > > two tags > > > > > > >>> should exist. > > > > > > >>> > > > > > > >>> In PerMsgStatus.pm I saw that everything is > prepared > > for the > > > two > > > > tags > > > > > > >>> but they finally not set (around line 1721). So > I > > changed to > > > > > > >>> > > > > > > >>>> if ($lasthop) { > > > > > > >>>>á á $self->set_tag('LASTEXTERNALIP',á $lasthop-> > {ip}); > > > > > > >>>>á á $self->set_tag('LASTEXTERNALRDNS', > $lasthop-> > > {rdns}); > > > > > > >>>>á á $self->set_tag('LASTEXTERNALHELO', > $lasthop-> > > {helo}); > > > > > > >>>>á } > > > > > > >>> > > > > > > >>> and --debug shows that the tags are now set and > the > > askdns > > > test is > > > > run. > > > > > > >>> > > > > > > >>> So I wonder if the code has just been forgotten > or if > > there > > > are > > > > deeper > > > > > > >>> reasons to not set the tags? > > > > > > >>> If no deeper reasons exist it would be nice to > have > > those two > > > tags > > > > set > > > > > > >>> as default in PerMsgStatus.pm > > > > > > >>> > > > > > > >>> > > > > > > >>> Cheers > > > > > > >>> > > > > > > >>> -- > > > > > > >>> > > > > > > >>> tobi > > > > > > >> > > > > > > >> -- > > > > > > >> Kevin A. McGrail > > > > > > >> kmcgr...@apache.org > > > > > > >> > > > > > > >> Member, Apache Software Foundation > > > > > > >> Chair Emeritus Apache SpamAssassin Project > > > > > > >> [5][6][7][8]https://www.linkedin.com/in/kmcgrail > - > > 703.798.0171 > > > > > > > > > > > > > > > > > > > References: > > > > > > > > [1] mailto:[7][8][9]h...@hege.li > > > > [2] [8][9][10]http://svn.apache.org/viewvc?view=revision&; > revision= > > 1870552 > > > > [3] mailto:[9][10][11]jahli...@gmx.ch > > > > [4] mailto:[10][11][12]jahli...@gmx.ch > > > > [5] [11][12][13]https://www.linkedin.com/in/kmcgrail > > > > > > > > > References: > > > > > > [1] mailto:[13][14]h...@hege.li > > > [2] mailto:[14][15]h...@hege.li > > > [3] [15][16]http://svn.apache.org/viewvc?view=revision&revision= > 1870552 > > > [4] mailto:[16][17]jahli...@gmx.ch > > > [5] mailto:[17][18]jahli...@gmx.ch > > > [6] [18][19]https://www.linkedin.com/in/kmcgrail > > > [7] mailto:[19][20]h...@hege.li > > > [8] [20][21]http://svn.apache.org/viewvc?view=revision&revision= > 1870552 > > > [9] mailto:[21][22]jahli...@gmx.ch > > > [10] mailto:[22][23]jahli...@gmx.ch > > > [11] [23][24]https://www.linkedin.com/in/kmcgrail > > > > > > References: > > > > [1] mailto:[25]h...@hege.li > > [2] mailto:[26]h...@hege.li > > [3] mailto:[27]h...@hege.li > > [4] [28]http://svn.apache.org/viewvc?view=revision&revision=1870552 > > [5] mailto:[29]jahli...@gmx.ch > > [6] mailto:[30]jahli...@gmx.ch > > [7] [31]https://www.linkedin.com/in/kmcgrail > > [8] mailto:[32]h...@hege.li > > [9] [33]http://svn.apache.org/viewvc?view=revision&revision=1870552 > > [10] mailto:[34]jahli...@gmx.ch > > [11] mailto:[35]jahli...@gmx.ch > > [12] [36]https://www.linkedin.com/in/kmcgrail > > [13] mailto:[37]h...@hege.li > > [14] mailto:[38]h...@hege.li > > [15] [39]http://svn.apache.org/viewvc?view=revision&revision=1870552 > > [16] mailto:[40]jahli...@gmx.ch > > [17] mailto:[41]jahli...@gmx.ch > > [18] [42]https://www.linkedin.com/in/kmcgrail > > [19] mailto:[43]h...@hege.li > > [20] [44]http://svn.apache.org/viewvc?view=revision&revision=1870552 > > [21] mailto:[45]jahli...@gmx.ch > > [22] mailto:[46]jahli...@gmx.ch > > [23] [47]https://www.linkedin.com/in/kmcgrail > > > References: > > [1] mailto:h...@hege.li > [2] mailto:h...@hege.li > [3] mailto:h...@hege.li > [4] mailto:h...@hege.li > [5] http://svn.apache.org/viewvc?view=revision&revision= > [6] mailto:jahli...@gmx.ch > [7] mailto:jahli...@gmx.ch > [8] https://www.linkedin.com/in/kmcgrail > [9] mailto:h...@hege.li > [10] http://svn.apache.org/viewvc?view=revision&revision= > [11] mailto:jahli...@gmx.ch > [12] mailto:jahli...@gmx.ch > [13] https://www.linkedin.com/in/kmcgrail > [14] mailto:h...@hege.li > [15] mailto:h...@hege.li > [16] http://svn.apache.org/viewvc?view=revision&revision=1870552 > [17] mailto:jahli...@gmx.ch > [18] mailto:jahli...@gmx.ch > [19] https://www.linkedin.com/in/kmcgrail > [20] mailto:h...@hege.li > [21] http://svn.apache.org/viewvc?view=revision&revision=1870552 > [22] mailto:jahli...@gmx.ch > [23] mailto:jahli...@gmx.ch > [24] https://www.linkedin.com/in/kmcgrail > [25] mailto:h...@hege.li > [26] mailto:h...@hege.li > [27] mailto:h...@hege.li > [28] http://svn.apache.org/viewvc?view=revision&revision=1870552 > [29] mailto:jahli...@gmx.ch > [30] mailto:jahli...@gmx.ch > [31] https://www.linkedin.com/in/kmcgrail > [32] mailto:h...@hege.li > [33] http://svn.apache.org/viewvc?view=revision&revision=1870552 > [34] mailto:jahli...@gmx.ch > [35] mailto:jahli...@gmx.ch > [36] https://www.linkedin.com/in/kmcgrail > [37] mailto:h...@hege.li > [38] mailto:h...@hege.li > [39] http://svn.apache.org/viewvc?view=revision&revision=1870552 > [40] mailto:jahli...@gmx.ch > [41] mailto:jahli...@gmx.ch > [42] https://www.linkedin.com/in/kmcgrail > [43] mailto:h...@hege.li > [44] http://svn.apache.org/viewvc?view=revision&revision=1870552 > [45] mailto:jahli...@gmx.ch > [46] mailto:jahli...@gmx.ch > [47] https://www.linkedin.com/in/kmcgrail
