Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: ovsqlite (Bo Lindbergh)
2. Re: ovsqlite (Julien ?LIE)
3. Re: ovsqlite (Russ Allbery)
4. Re: ovsqlite (Julien ?LIE)
5. Re: ovsqlite (Julien ?LIE)
6. Re: Stop rejection due to bad dates (Jeffery Small)
7. Re: silently ignore duplicate inews via mailpost (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Dec 2020 16:53:09 +0100
From: Bo Lindbergh <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Quoth Julien ?LIE <[email protected]>:
> Can I put credits for you in a comment at the beginning of a few source files?
Go ahead.
/Bo Lindbergh
------------------------------
Message: 2
Date: Fri, 18 Dec 2020 19:40:51 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
>> At long last, ovsqlite! In two patches to be applied in sequence on top
>> of svn revision 10453.
>
> Thank you so much for working on this! I'm very excited by the idea. It
> feels like a great way to do overview that will be easier to maintain.
INN 2.6.4 will certainly be released in January.
The new ovsqlite overview method could be part of the release, and
explicitly mentioned as experimental, so that to eventually have more
feedback. It indeed does not modify other overview methods, remaining
as stable as before.
Poll: do you prefer ovsqlite to be in upcoming INN 2.6.4 or delayed for
INN 2.6.5? (Only CURRENT would then have it.)
--
Julien ?LIE
??? Nous voyageons plus vite que la lumi?re?!
? Alors comment y voir clair dans tout ?a???? (Ast?rix)
------------------------------
Message: 3
Date: Fri, 18 Dec 2020 10:57:06 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> INN 2.6.4 will certainly be released in January.
> The new ovsqlite overview method could be part of the release, and
> explicitly mentioned as experimental, so that to eventually have more
> feedback. It indeed does not modify other overview methods, remaining as
> stable as before.
> Poll: do you prefer ovsqlite to be in upcoming INN 2.6.4 or delayed for
> INN 2.6.5? (Only CURRENT would then have it.)
A new overview mechanism feels kind of like an INN 2.7.0 thing to me.
Seems worth celebrating with a version bump!
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 4
Date: Fri, 18 Dec 2020 20:18:09 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
>> Poll: do you prefer ovsqlite to be in upcoming INN 2.6.4 or delayed for
>> INN 2.6.5? (Only CURRENT would then have it.)
>
> A new overview mechanism feels kind of like an INN 2.7.0 thing to me.
> Seems worth celebrating with a version bump!
:-)
Sounds great!
So maybe we should focus our efforts next year on patches and changes
that cannot be integrated in minor releases:
- dropping obsolete features (like #150 old Python and Perl wrappers for
hooks pre-dating INN 2.4.0)
- renaming options (like #143 require_encryption in readers.conf instead
of require_ssl, and include SASL security layers in it)
- API changes
And new other features like Cancel-Lock support, the long-awaited
compliance of innfeed with RFC 3977, supporting CAPABILITIES,
installation in FHS paths, authenticated Path header support...
Lots of ideas in Trac and TODO!
--
Julien ?LIE
??Give laugh to all but smile to one,
Give cheeks to all but lips to one,
Give love to all but Heart to one,
Let everybody love you
But you love one.??
------------------------------
Message: 5
Date: Fri, 18 Dec 2020 22:03:27 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: ovsqlite
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Bo,
> The first patch is split out because it has general utility,
> not specific to ovsqlite.
>
> I use some generated files, so I wanted to enhance storage/buildconfig
> to add lists of files to be removed at various cleanup levels.
> METHOD_SOURCES, EXTRA_SOURCES, and PROGRAMS were handled by separate
> code paths that were identical except for the names. This cried out
> to be replaced by a table-driven approach, so that's what I did.
>
> The Makefile-related data could end up in either %storage or %overview,
> and so had to be merged and re-sorted before Make.methods could be written.
> I changed this to use a new %makefile variable containing
> the Makefile-related data for both storage and overview methods.
A useful enhancement, indeed!
Just merged upstream.
> More testing is needed; I've only used the hardware I've got at home,
> which is all x86_64 (macOS 10.15 and Fedora 33).
There's an issue with the second patch when SQLite is not installed
(HAVE_SQLITE3 unset).
The build fails because buffer_t is an unknown type in
ovsqlite/ovsqlite-private.c (not defined in the
ovsqlite/ovsqlite-private.h header when HAVE_SQLITE3 is unset).
Maybe ovsqlite should just not be built when SQLite is not installed?
(like authprogs/auth_krb5 is not built when Kerberos v5 is not installed)
--
Julien ?LIE
??Ils ont de ces armes secr?tes, les Gaulois, qui devraient ?tre
interdites par la commission internationale des Helv?tes?!?? (Ast?rix)
------------------------------
Message: 6
Date: Fri, 18 Dec 2020 13:24:24 -0800
From: Jeffery Small <[email protected]>
To: Mailing Lists <[email protected]>
Subject: Re: Stop rejection due to bad dates
Message-ID:
<CAOLErMW=yvVQ6-E-qeWPTM3cG6fwv3+Kgcfq-XkhsN2ie=x...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Julien ?LIE wrote:
> You should make sure the rejection is really caused by that field.
> The reason is written in your news log files.
>
> As a matter of fact, INN rejects articles posted 24h in the future, as
> required by standards. It does not reject an article posted 5h in the
> future
Well, that's just it. There are no errors reported in the inn2 logs.
My errlog and news.err files are always empty and news file just
has normal entries for input actually posted.
I've always assumed that the mailagent errors were the result of
an actual inn2 post that was rejected and never understood why
error logging wasn't happening, but maybe it is all internal to
mailagent and the article is never attempted to be posted at all.
I'll try to track this posting action down in the source code and see
just what is going on.
Russ Allbery wrote:
> When I was gating dodgy email into Usenet groups, I sometimes
> found it easier to just rename the Date header to X-Original-Date
> in the preprocessing step rather than messing with it. That way
> the original data is there if you care, but you don't have to do a
> lot of work.
Great idea.
Thank you both for the excellent feedback. I'll dig deeper and see
what else I can discover.
Regards,
--
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/inn-workers/attachments/20201218/c115e4f7/attachment-0001.htm>
------------------------------
Message: 7
Date: Fri, 18 Dec 2020 23:10:43 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Cc: Harald Dunkel <[email protected]>
Subject: Re: silently ignore duplicate inews via mailpost
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Harald,
> CUSTOMER_BOSS: "|/usr/lib/news/bin/mailpost -c 15 -b /var/tmp -x To:CC
> example.projects.CUSTOMER_BOSS"
>
> The header I received within the mailpost failure message was
>
> From: [email protected] (Anja)
> Newsgroups: example.projects.CUSTOMER_BOSS
> Cc: CUSTOMER_BOSS <[email protected]>
> Message-ID: <[email protected]>
>
> As you can see, Anja posted the article twice: Once per Newsgroup
> integration
> in Thunderbird, and once via the "short" EMail alias. I cannot blame
> Anja here.
> She just clicked on [reply to all].
OK, that's pretty clear.
> Question was whether it would be possible to silently ignore the
> duplicate article without sending a mailpost failure EMail?
Is the subject of the mailpost failure mail "inews failed: inews: cannot
send article to server: 441 435 Duplicate inews: article not posted"?
Unfortunately, there's currently no way to silent that error without
modifying the mailpost script. The "-n" flag to mailpost prevents both
postings and sending mail errors (and not only that second part).
Is it possible for you to modify mailpost?
If that is the case, near line 538, just change:
if (@inews) {
chomp @inews ;
mailArtAndDie ("inews failed: @inews") ;
}
to:
if (@inews) {
chomp @inews ;
mailArtAndDie ("inews failed: @inews")
unless ($inews[0] =~ /441 435 Duplicate/g);
}
I believe it will fix the problem you're facing.
Please tell me if that does the trick (now that you know how to
reproduce it, you may try to trigger it).
--
Julien ?LIE
??? Ordre est donn? d'enqu?ter dans tout le secteur, afin d'identifier
et de confondre les l?gions ? la solde de Pomp?e?!
? S'ils n'ont pas de signes distinctifs, ?a ne sera pas facile mon
g?n?ral?!?? (Ast?rix)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 126, Issue 10
********************************************
