The /etc/myname file is processed by rc(8), not netstart(8) as currently
indicated by the myname(5) man page. This patch corrects the myname(5) man
page to state myname is processed by rc.
Index: myname.5
===
RCS file:
Scott Cheloha wrote:
> > +Exceedingly large timing arguments are succeptable to truncation.
> >
> > Rough warning feels like it is enough.
>
> Do you mean truncation or overflow?
Maybe, once again, accurately explain the problem.
Exceedingly large timing arguments will perform incorrectly
Scott Cheloha wrote:
> FWIW, the manpage has literally always led with this bolded
> implementation detail. From January of 1986:
>
> https://svnweb.freebsd.org/csrg/lib/libc/gen/ualarm.3?revision=25789=markup
I'm just saying it is uninformative and distracting.
> ... specifically,
On Wed, Jun 30, 2021 at 04:50:27PM -0600, Theo de Raadt wrote:
> Todd C. Miller wrote:
>
> > On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
> >
> > > Can the current wording below CAVEATS, "confusing behavior", be made
> > > more precise, explaining what actually happens rather than
On Wed, Jun 30, 2021 at 04:23:42PM -0600, Theo de Raadt wrote:
> >Uh, oh, to my naive ears (naive with respect to matters of time-related
> >functions), this sounds like a typical case where we likely want one
> >manual page documenting both alarm(3) and ualarm(3), not two pages.
> >
> >Basically,
Todd C. Miller wrote:
> On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
>
> > Can the current wording below CAVEATS, "confusing behavior", be made
> > more precise, explaining what actually happens rather than merely
> > calling it "confusing"? For example, saying that they all
Todd C. Miller wrote:
> > I think it would be ideal for the manual page text to state
> > which values can be used in a *portable* way. If, for some reason,
> > that is not desirable, then the main text should say which values
> > can be used on OpenBSD, and STANDARDS should say that using
On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
> Can the current wording below CAVEATS, "confusing behavior", be made
> more precise, explaining what actually happens rather than merely
> calling it "confusing"? For example, saying that they all override
> each other or something like
On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
> I'm confused. It seems i fail to find useconds_t in POSIX.
> I only see suseconds_t there, in , which must be signed,
> include [-1, 100], and not be wider than long. Also, our manual
> says ualarm(3) is -xpg4.2. That's basically
>Uh, oh, to my naive ears (naive with respect to matters of time-related
>functions), this sounds like a typical case where we likely want one
>manual page documenting both alarm(3) and ualarm(3), not two pages.
>
>Basically, the rule of thumb is: if two functions have a very similar
>purpose,
Hi Scott,
Scott Cheloha wrote on Wed, Jun 30, 2021 at 03:15:31PM -0500:
> As it would turn out, there are not one, but *two* simplified
> interfaces to setitimer(2). We just cleaned up the alarm(3) manpage,
> but did you know there is also a ualarm(3) interface?
I certainly didn't... :-)
>
Hi,
As it would turn out, there are not one, but *two* simplified
interfaces to setitimer(2). We just cleaned up the alarm(3) manpage,
but did you know there is also a ualarm(3) interface?
Luckily it's basically the same interface as alarm(3). So, I have
taken the rewritten manpage from
Hi Emil,
Emil Engler wrote on Wed, Jun 30, 2021 at 07:09:27PM +0200:
> The pledge.2 man-page makes use of the incorrect .Ar macro which is
> not intended for manuals in section 2 as .Fa exists for that purpose.
> Similar to 1.18 in /cvs/src/lib/libm/man/sqrt.3
Note that the pledge(2) manual
Chris Narkiewicz [he...@ezaquarii.com] wrote:
> On Wed, Jan 29, 2020 at 10:47:28PM +0800, Nathanael Rensen wrote:
> > The diff below adds gpio(4) support to wbsio(4) for Nuvoton NCT5104D
> > (pcengines APU2).
>
> I'm resurrecting this thread. I was looking for GPIO support for APU2
> board and
The pledge.2 man-page makes use of the incorrect .Ar macro which is
not intended for manuals in section 2 as .Fa exists for that purpose.
Similar to 1.18 in /cvs/src/lib/libm/man/sqrt.3
Index: pledge.2
===
RCS file:
Thge compare-dest option of rsync is something I would like to use in
rpki-client. This implements just that and I think after that adding
copy-dest and link-dest options should be somewhat easy to add as well.
Lightly tested with my particular need.
--
:wq Claudio
Index: Makefile
Hey,
this works fine on my systems. Nothing breaks so far. This ist just as
feedback to you.
Thanks and greetings
Leo
Am 30.06.2021 um 14:37 schrieb Eric Faurot:
Except for specific cases, SMTP servers do not expect client
certificates for TLS sessions. The log message for missing
On Wed, 30 Jun 2021 14:37:44 +0200, Eric Faurot wrote:
> Except for specific cases, SMTP servers do not expect client
> certificates for TLS sessions. The log message for missing certificate
> is not very useful in practice (handshake fails before if it was
> required anyway), and it is even
Hi,
I may have seen it elsewhere, or probably not, but after checking on kn's commit
to tls_load_file(3) it seems it's now possible to set the ca/cert/key directly
without having to load them first from disk and set them afterwards from memory.
That being said the below applies this to spamd(8),
Except for specific cases, SMTP servers do not expect client
certificates for TLS sessions. The log message for missing certificate
is not very useful in practice (handshake fails before if it was
required anyway), and it is even confusing for people.
I think it can go away.
Eric.
Index:
On Tue, May 25, 2021 at 03:48:16PM +0200, Stefan Sperling wrote:
> This patch allows iwm(4) to use new firmware images which are part
> of the iwm-20210512 firmware package, available via fw_update (you
> need to run fw_update *before* booting with this patch).
Here is a rebased version of the
On Mon, Jun 21, 2021 at 08:37:11PM +0200, Stefan Sperling wrote:
> This patch attempts to implement Tx aggregation support for iwx(4).
>
> It is not yet ready to be committed because of outstanding problems:
>
> - Under load the firmware throws a fatal firmware error every few minutes.
>
> -
On 21/06/21(Mon) 23:45, Alexander Bluhm wrote:
> On Thu, Jun 17, 2021 at 03:19:11PM +0200, Alexander Bluhm wrote:
> > On Thu, Jun 17, 2021 at 10:09:47AM +0200, Martin Pieuchot wrote:
> > > Could you annotate which field is being protected by the KERNEL_LOCK()?
> >
> > No. I do not want to invest
On Tue, Jun 29, 2021 at 10:38:33PM -0700, pion wrote:
> I’m interested in porting OpenBSD to the Nuvoton NUC980, which uses an
> ARM926EJ-S core. I discovered that arm9 support was removed in 2016 and found
> the relevant patches in tech@. It seems that the rationale was that arm8/9
> platforms
I’m interested in porting OpenBSD to the Nuvoton NUC980, which uses an
ARM926EJ-S core. I discovered that arm9 support was removed in 2016 and found
the relevant patches in tech@. It seems that the rationale was that arm8/9
platforms were not being used with OpenBSD and were therefore a source
25 matches
Mail list logo
