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. Build system changes (Russ Allbery)
2. Re: Build system changes (Richard Kettlewell)
3. Re: Build system changes (Julien ?LIE)
4. Re: INN indentation (Julien ?LIE)
5. Re: Discussion about Cancel-Lock support (Julien ?LIE)
6. Re: NNTPS pointers (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Oct 2021 08:44:04 -0700
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Build system changes
Message-ID: <[email protected]>
Content-Type: text/plain
I'm currently working on converting INN's build system to non-recursive
Automake. This is something I've wanted to do for years, although the
problem that got me to finally start is
https://github.com/InterNetNews/inn/issues/206.
There are a few things that INN currently does in its build system which
are sort of easy (or at least possible) to do with hand-rolled Makefiles,
but which don't entirely fit Automake's model. We could do some extra
work to reproduce them, but I think changing how the build system works
minorly to be more in-line with Automake's expectations may make things
more maintainable in the long run.
These changes (and indeed all of the Automake work) would only be in the
main branch, not in the 2.6 release branch.
I haven't found everything, but a few things for people to think about to
start with:
1. The pluggable storage, overview, and history mechanism, where we
generate build rules at build time, is possible with Automake but it
would add a fair amount of complexity. I feel like it's a very
uncommon operation to add a new storage, overview, or history backend,
and if one is doing this, modifying the top-level Makefile.am is the
least part of that work, so we should drop that level of dynamic
generation. However, what would be useful is to not build backends
whose dependencies aren't available. (For example, we shouldn't build
ovdb if we don't have BerkeleyDB, and then attempting to use it should
be an error.)
Automake provides conditional compilation that would let us do exactly
this, in combination with some preprocessor logic in files like
ovmethods.c. My inclination is to go in that direction: the build
rules will always be present in the top-level Makefile.am, but
(eventually, probably not in the first PR) conditional on whether we
have the prerequisites to build that backend.
2. I'd like to look at using that same conditional compilation approach
for the embedded Perl and Python support. We could then drop the
preprocessor guards on those files, only guard the invocations of the
functions they export (and possibly stub them out with a clever header
file to reduce the amount of conditional compilation), and then choose
whether to link them into the binaries based on Automake conditionals.
Note that, to support using different compilation flags for those
files, they'll actually be built as libtool convenience libraries when
using an Automake build system. (This should be invisible to anyone
building INN.)
3. There are profiling rules scattered around the INN build system, but
I've never used them and I'm not sure they work as-is. I also don't
know how to convert them to Automake. I currently intend to drop
them.
4. Having the man pages and POD source in different directories makes it
hard to write suffix rules to convert POD to man pages. I'd like to
unify the man and pod directories so that the man pages are generated
beside the POD source for that page, since that will avoid a bunch of
tedious copy-paste rules for each individual page.
5. I'm inclined to move the POD source for files like INSTALL, NEWS,
and README to live alongside those files (so INSTALL.pod, NEWS.pod,
and README.pod). This doesn't really make much difference for the
build system, but it will provide nicer rendering on GitHub. Might
make sense to do something similar with the files in the top level of
doc. That would essentially empty out the doc/pod directory in favor
of moving the POD source next to the generated file.
6. As previously discussed, the MANIFEST file doesn't do anything under
Automake (it has its own mechanism for tracking what goes into a
distribution), so I'd like to drop it.
7. The easy way to implement the special ownership and permission rules
for some INN files is to install them with regular permissions and then
fix the permissions afterwards with install-exec-hook. That does mean
there will be a window where the permissions will be wrong. Does that
seem okay?
I haven't yet figured out how to support the -S .OLD option to install.
Not sure yet how hard that will be. I'm planning on keeping the site
directory as-is and invoking it via recursive make, at least for now.
--
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: 2
Date: Thu, 21 Oct 2021 17:18:38 +0100
From: Richard Kettlewell <[email protected]>
To: [email protected]
Subject: Re: Build system changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 21/10/2021 16:44, Russ Allbery wrote:
> 1. The pluggable storage, overview, and history mechanism, where we
> generate build rules at build time, is possible with Automake but it
> would add a fair amount of complexity. I feel like it's a very
> uncommon operation to add a new storage, overview, or history backend,
> and if one is doing this, modifying the top-level Makefile.am is the
> least part of that work, so we should drop that level of dynamic
> generation.
This was a big source of confusion while analyzing #206, so I'll be glad
to see the back of it.
ttfn/rjk
------------------------------
Message: 3
Date: Thu, 21 Oct 2021 22:00:47 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Build system changes
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> These changes (and indeed all of the Automake work) would only be in the
> main branch, not in the 2.6 release branch.
Many thanks to tackle that work!
For the 2.6 release branch, maybe we could just take Richard's work on #206.
> 3. There are profiling rules scattered around the INN build system, but
> I've never used them and I'm not sure they work as-is. I also don't
> know how to convert them to Automake. I currently intend to drop
> them.
I've also never used it.
> 7. The easy way to implement the special ownership and permission rules
> for some INN files is to install them with regular permissions and then
> fix the permissions afterwards with install-exec-hook. That does mean
> there will be a window where the permissions will be wrong. Does that
> seem okay?
If that's the usual way to do it, that seems OK.
> I haven't yet figured out how to support the -S .OLD option to install.
> Not sure yet how hard that will be. I'm planning on keeping the site
> directory as-is and invoking it via recursive make, at least for now.
Do you use Automake 1.16.3 or later?
Support for the -S .OLD option has been added to install-sh in Automake
1.16.3 (released in November 2020).
--
Julien ?LIE
??Attention aux bugs dans le code ci-dessus. Je ne l'ai pas test?, j'ai
seulement prouv? qu'il ?tait correct.?? (Donald Knuth)
------------------------------
Message: 4
Date: Thu, 21 Oct 2021 22:09:04 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: INN indentation
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi all,
>> AlignConsecutiveMacros: AcrossEmptyLinesAndComments
>> may be better but only available in clang-format 13 (not yet released!)
>> It think it would permit to have 62 at the same level here:
>
>> #if defined(HAVE_OPENSSL) || defined(HAVE_SASL)
>> # define PERMrequire_ssl 62
>> # define PERMMAX 63
>> #else
>> # define PERMMAX 62
>> #endif
>
> Oh, that will be very nice once that's released. That's one of the
> formatting decisions that always bugged me.
Sure it will be nice!
Amusingly, I've found out a drawback of alignment, in nnrpd/line.c:
zstream_inflate_needed = true;
n = 0;
}
#endif /* HAVE_ZLIB */
} while (n == 0); /* Split SASL blob, need to read more data. */
return n;
}
I think clang-format should not align these comments, it seems weird.
But well, comments are aligned!
--
Julien ?LIE
??Attention aux bugs dans le code ci-dessus. Je ne l'ai pas test?, j'ai
seulement prouv? qu'il ?tait correct.?? (Donald Knuth)
------------------------------
Message: 5
Date: Thu, 21 Oct 2021 22:21:55 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Discussion about Cancel-Lock support
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi Russ,
> Personally, I'd be happy to never have to write cryptic configuration lke:
>
> news.uu.net/uunet\
> :*,!junk,!control,!control.*/!foo\
> :Tm:innfeed!
I bet you also love the syntax of innwatch.ctl :-)
!load!+! uptime | tr -d ,. | awk '{ print $(NF - 2) }' ! gt !
${INNWATCHPAUSELOAD} ! pause ! loadav
> I think the question is whether having a
> cleaner config syntax with more human-readable options and schema checking
> is enough of an advantage over, say, the current cryptic newsfeeds syntax
> to be worth introducing a whole new config syntax after all this time.
That's a good question.
We have lots of examples in the newsfeeds sample file, so normally it is
not too difficult to find out the right syntax for a basic feed.
Most of the questions come from readers.conf... which has a cleaner syntax!
> If we did something like this, it also opens the interesting possibility
> of rethinking how configuration is broken up between files. It's pretty
> irritating right now to have to modify three different files with entirely
> different syntax to add a new peer, and we could fix that.
It is true that having only one file to set up a peer would be good,
mixing newsfeeds/incoming.conf/innfeed.conf configuration for the peer.
>> The drawbacks I would see for YAML is that we add a library dependency to
>> libyaml, hoping it is available in all the platforms we support (libyaml
>> seems more wide-spread than libfyaml).
>
> Yes, this is a potentially serious drawback for folks who are building INN
> themselves on platforms other than Linux.
Seems like the only real argument for not using YAML.
If we speak of the syntax, what you implemented in the "new" parser is
pretty good, YAML-like, and perfectly fits the needs of INN.
So maybe we should just keep this parser and go ahead with it?
Does anyone here have another opinion?
>> And personally I like its way to write lists ([a b c]) more than YAML
>> does (multi-lines).
>
> Little known fact: [a, b, c] is also valid YAML!
Oh, I did not know. The summaries I read about YAML did not show that
syntax.
--
Julien ?LIE
??Attention aux bugs dans le code ci-dessus. Je ne l'ai pas test?, j'ai
seulement prouv? qu'il ?tait correct.?? (Donald Knuth)
------------------------------
Message: 6
Date: Thu, 21 Oct 2021 22:37:09 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: NNTPS pointers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Responding to myself,
> Do you know news servers implementing TLS for transit?
>
> If that's the case, as nnrpd has TLS support and implements IHAVE, maybe
> you could try to start 2 instances of nnrpd (one listening to port 563
> for readers, and another to port 433 for instance).? Remote news servers
> may send you articles to port 433 using TLS and IHAVE.
> I believe it would work.? Yet, not as fast as innd would, though.
On second thoughts, and having verified how IHAVE is delt with by nnrpd,
this will not work. Articles from peers will be rejected; nnrpd acts as
an injecting agent, whatever command is used. So articles from peers
will be rejected as they contain header fields showing they have already
been injected.
That's not possible then.
Another secure way to feed articles would be UUCP batches over SSH (with
send-uucp) but it may not fit your needs, Grant.
> And innfeed does not implement TLS either...
At one time we could have the debate of switching innfeed to innduct
https://www.chiark.greenend.org.uk/ucgi/~ian/git-manpage/innduct.git/innduct.8
It will be easier to implement TLS support in innduct, and also to
maintain it. Besides, I doubt all the configuration possibilities
innfeed has to fine-tune its behaviour is really used in practice...
AUTHINFO would be worth adding to innduct though.
And if imapfeed is still used (I don't know if it still works fine), it
could maybe be integrated as imapduct!
--
Julien ?LIE
??Apr?s la clairi?re d'attente, on entre dans la hutte de
consultation.?? (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 134, Issue 11
********************************************
