Send inn-committers mailing list submissions to
inn-committers@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-committers
or, via email, send a message with subject or body 'help' to
inn-committers-requ...@lists.isc.org
You can reach the person managing the list at
inn-committers-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-committers digest..."
Today's Topics:
1. INN commit: trunk/doc/pod (4 files) (INN Commit)
2. INN commit: trunk/doc/pod (incoming.conf.pod) (INN Commit)
3. INN commit: branches/2.5/doc/pod (4 files) (INN Commit)
4. INN commit: branches/2.5/doc/pod (incoming.conf.pod) (INN Commit)
5. INN commit: branches/2.5/m4 (berkeleydb.m4) (INN Commit)
----------------------------------------------------------------------
Message: 1
Date: Thu, 19 Dec 2013 09:46:42 -0800 (PST)
From: INN Commit <r...@isc.org>
To: inn-committ...@isc.org
Subject: INN commit: trunk/doc/pod (4 files)
Message-ID: <20131219174642.334b267...@hope.eyrie.org>
Date: Thursday, December 19, 2013 @ 09:46:41
Author: iulius
Revision: 9588
mention innduct as a possible replacement for innfeed, innxmit and nntpsend
Modified:
trunk/doc/pod/innfeed.pod
trunk/doc/pod/innxmit.pod
trunk/doc/pod/nntpsend.pod
trunk/doc/pod/readme.pod
--------------+
innfeed.pod | 12 ++++++++++++
innxmit.pod | 3 +++
nntpsend.pod | 3 +++
readme.pod | 10 ++++++++++
4 files changed, 28 insertions(+)
Modified: innfeed.pod
===================================================================
--- innfeed.pod 2013-12-14 20:10:48 UTC (rev 9587)
+++ innfeed.pod 2013-12-19 17:46:41 UTC (rev 9588)
@@ -438,6 +438,18 @@
Probably too many other bugs to count.
+=head1 ALTERNATIVE
+
+An alternative to B<innfeed> can be
+B<innduct>, maintained by Ian Jackson and available at
+L<http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8>.
+It is intended to solve a design issue in the way B<innfeed> works.
+As a matter of fact, the program feed protocol spoken between B<innd>
+and B<innfeed> is lossy: if B<innfeed> dies unexpectedly, articles
+which B<innd> has written to the pipe to B<innfeed> will be skipped.
+B<innd> has no way of telling which articles those are, no useful
+records, and no attempts to resend these articles.
+
=head1 FILES
=over 4
Modified: innxmit.pod
===================================================================
--- innxmit.pod 2013-12-14 20:10:48 UTC (rev 9587)
+++ innxmit.pod 2013-12-19 17:46:41 UTC (rev 9588)
@@ -33,6 +33,9 @@
the batch file to contain the current article and any other unsent
articles.
+An alternative to B<innxmit> can be B<innduct>, mentioned in the
+innfeed(8) man page.
+
=head1 OPTIONS
=over 4
Modified: nntpsend.pod
===================================================================
--- nntpsend.pod 2013-12-14 20:10:48 UTC (rev 9587)
+++ nntpsend.pod 2013-12-19 17:46:41 UTC (rev 9588)
@@ -31,6 +31,9 @@
flags for that site. Any flags given on the command line override the
default flags for the site.
+An alternative to B<nntpsend> can be B<innduct>, mentioned in the
+innfeed(8) man page.
+
=head1 OPTIONS
=over 2
Modified: readme.pod
===================================================================
--- readme.pod 2013-12-14 20:10:48 UTC (rev 9587)
+++ readme.pod 2013-12-19 17:46:41 UTC (rev 9588)
@@ -244,6 +244,16 @@
time. It's useful when feeding peers take limited and very specific
feeds that change periodically.
+=item innduct
+
+URL:
L<http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8>
(maintained by Ian Jackson)
+
+A possible replacement for B<innfeed>, B<innxmit> and B<nntpsend>
+that quickly and reliably streams Usenet article to a remote site.
+B<innduct> is designed to be robust and not to lose any articles (when
+offered to peers) in case it unexpectedly dies, contrary to B<innfeed>.
+It also permits a realtime feed, contrary to B<innxmit> or B<nntpsend>.
+
=item NewsPortal
URL: L<http://amrhein.eu/newsportal/doc/>
------------------------------
Message: 2
Date: Thu, 19 Dec 2013 09:47:33 -0800 (PST)
From: INN Commit <r...@isc.org>
To: inn-committ...@isc.org
Subject: INN commit: trunk/doc/pod (incoming.conf.pod)
Message-ID: <20131219174733.c535f67...@hope.eyrie.org>
Date: Thursday, December 19, 2013 @ 09:47:33
Author: iulius
Revision: 9589
rewording so as to make the documentation of noresendid clearer
Modified:
trunk/doc/pod/incoming.conf.pod
-------------------+
incoming.conf.pod | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
Modified: incoming.conf.pod
===================================================================
--- incoming.conf.pod 2013-12-19 17:46:41 UTC (rev 9588)
+++ incoming.conf.pod 2013-12-19 17:47:33 UTC (rev 9589)
@@ -145,13 +145,15 @@
=item I<noresendid>
-This key requires a boolean value. It defines whether B<innd> should send
-C<431> (response to CHECK, in streaming mode) or C<436> (response to IHAVE
-in non-streaming mode) responses instead of C<438> (response to CHECK)
-or C<435> (response to IHAVE) if a message is offered that is already
-received from another peer. This can be useful for peers that resend
-messages right away, as innfeed does. The default is false: the peer
-receives C<431> and C<436> codes so that it resends the article later.
+This key requires a boolean value. It defines whether B<innd> should
+send C<438> (response to CHECK, in streaming mode) or C<435> (response
+to IHAVE in non-streaming mode) responses instead of C<431> (response
+to CHECK) or C<436> (response to IHAVE) if a message is offered that
+is already received from another peer. The deferral feature can be
+useful for peers that resend messages right away, as B<innfeed> does.
+The default is false: the deferral feature is used so that the peer
+receives C<431> and C<436> codes, and therefore resends the article
+later.
=item I<password>
------------------------------
Message: 3
Date: Thu, 19 Dec 2013 09:48:22 -0800 (PST)
From: INN Commit <r...@isc.org>
To: inn-committ...@isc.org
Subject: INN commit: branches/2.5/doc/pod (4 files)
Message-ID: <20131219174822.ef90467...@hope.eyrie.org>
Date: Thursday, December 19, 2013 @ 09:48:22
Author: iulius
Revision: 9590
mention innduct as a possible replacement for innfeed, innxmit and nntpsend
Modified:
branches/2.5/doc/pod/innfeed.pod
branches/2.5/doc/pod/innxmit.pod
branches/2.5/doc/pod/nntpsend.pod
branches/2.5/doc/pod/readme.pod
--------------+
innfeed.pod | 12 ++++++++++++
innxmit.pod | 3 +++
nntpsend.pod | 3 +++
readme.pod | 10 ++++++++++
4 files changed, 28 insertions(+)
Modified: innfeed.pod
===================================================================
--- innfeed.pod 2013-12-19 17:47:33 UTC (rev 9589)
+++ innfeed.pod 2013-12-19 17:48:22 UTC (rev 9590)
@@ -438,6 +438,18 @@
Probably too many other bugs to count.
+=head1 ALTERNATIVE
+
+An alternative to B<innfeed> can be
+B<innduct>, maintained by Ian Jackson and available at
+L<http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8>.
+It is intended to solve a design issue in the way B<innfeed> works.
+As a matter of fact, the program feed protocol spoken between B<innd>
+and B<innfeed> is lossy: if B<innfeed> dies unexpectedly, articles
+which B<innd> has written to the pipe to B<innfeed> will be skipped.
+B<innd> has no way of telling which articles those are, no useful
+records, and no attempts to resend these articles.
+
=head1 FILES
=over 4
Modified: innxmit.pod
===================================================================
--- innxmit.pod 2013-12-19 17:47:33 UTC (rev 9589)
+++ innxmit.pod 2013-12-19 17:48:22 UTC (rev 9590)
@@ -33,6 +33,9 @@
the batch file to contain the current article and any other unsent
articles.
+An alternative to B<innxmit> can be B<innduct>, mentioned in the
+innfeed(8) man page.
+
=head1 OPTIONS
=over 4
Modified: nntpsend.pod
===================================================================
--- nntpsend.pod 2013-12-19 17:47:33 UTC (rev 9589)
+++ nntpsend.pod 2013-12-19 17:48:22 UTC (rev 9590)
@@ -31,6 +31,9 @@
flags for that site. Any flags given on the command line override the
default flags for the site.
+An alternative to B<nntpsend> can be B<innduct>, mentioned in the
+innfeed(8) man page.
+
=head1 OPTIONS
=over 2
Modified: readme.pod
===================================================================
--- readme.pod 2013-12-19 17:47:33 UTC (rev 9589)
+++ readme.pod 2013-12-19 17:48:22 UTC (rev 9590)
@@ -240,6 +240,16 @@
time. It's useful when feeding peers take limited and very specific
feeds that change periodically.
+=item innduct
+
+URL:
L<http://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8>
(maintained by Ian Jackson)
+
+A possible replacement for B<innfeed>, B<innxmit> and B<nntpsend>
+that quickly and reliably streams Usenet article to a remote site.
+B<innduct> is designed to be robust and not to lose any articles (when
+offered to peers) in case it unexpectedly dies, contrary to B<innfeed>.
+It also permits a realtime feed, contrary to B<innxmit> or B<nntpsend>.
+
=item NewsPortal
URL: L<http://amrhein.eu/newsportal/doc/>
------------------------------
Message: 4
Date: Thu, 19 Dec 2013 09:48:54 -0800 (PST)
From: INN Commit <r...@isc.org>
To: inn-committ...@isc.org
Subject: INN commit: branches/2.5/doc/pod (incoming.conf.pod)
Message-ID: <20131219174855.034f167...@hope.eyrie.org>
Date: Thursday, December 19, 2013 @ 09:48:54
Author: iulius
Revision: 9591
rewording so as to make the documentation of noresendid clearer
Modified:
branches/2.5/doc/pod/incoming.conf.pod
-------------------+
incoming.conf.pod | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
Modified: incoming.conf.pod
===================================================================
--- incoming.conf.pod 2013-12-19 17:48:22 UTC (rev 9590)
+++ incoming.conf.pod 2013-12-19 17:48:54 UTC (rev 9591)
@@ -145,13 +145,15 @@
=item I<noresendid>
-This key requires a boolean value. It defines whether B<innd> should send
-C<431> (response to CHECK, in streaming mode) or C<436> (response to IHAVE
-in non-streaming mode) responses instead of C<438> (response to CHECK)
-or C<435> (response to IHAVE) if a message is offered that is already
-received from another peer. This can be useful for peers that resend
-messages right away, as innfeed does. The default is false: the peer
-receives C<431> and C<436> codes so that it resends the article later.
+This key requires a boolean value. It defines whether B<innd> should
+send C<438> (response to CHECK, in streaming mode) or C<435> (response
+to IHAVE in non-streaming mode) responses instead of C<431> (response
+to CHECK) or C<436> (response to IHAVE) if a message is offered that
+is already received from another peer. The deferral feature can be
+useful for peers that resend messages right away, as B<innfeed> does.
+The default is false: the deferral feature is used so that the peer
+receives C<431> and C<436> codes, and therefore resends the article
+later.
=item I<password>
------------------------------
Message: 5
Date: Thu, 19 Dec 2013 09:49:32 -0800 (PST)
From: INN Commit <r...@isc.org>
To: inn-committ...@isc.org
Subject: INN commit: branches/2.5/m4 (berkeleydb.m4)
Message-ID: <20131219174932.5297267...@hope.eyrie.org>
Date: Thursday, December 19, 2013 @ 09:49:31
Author: iulius
Revision: 9592
fix typo
Modified:
branches/2.5/m4/berkeleydb.m4
---------------+
berkeleydb.m4 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Modified: berkeleydb.m4
===================================================================
--- berkeleydb.m4 2013-12-19 17:48:54 UTC (rev 9591)
+++ berkeleydb.m4 2013-12-19 17:49:31 UTC (rev 9592)
@@ -65,7 +65,7 @@
}
]])
-dnl Check whether Berkeley DB was compiled with ndbm compatibily layer.
+dnl Check whether Berkeley DB was compiled with ndbm compatibility layer.
dnl If so, set HAVE_BDB_NDBM.
AC_DEFUN([INN_LIB_BERKELEYDB_NDBM],
[inn_save_LDFLAGS="$LDFLAGS"
------------------------------
_______________________________________________
inn-committers mailing list
inn-committers@lists.isc.org
https://lists.isc.org/mailman/listinfo/inn-committers
End of inn-committers Digest, Vol 58, Issue 5
*********************************************
