Re: smtpd: more unused code

Eric Faurot writes: > Certificate verification is done by libtls. The former code is not used > anymore and can be unplugged. Should cert.c be removed? I don't think it's used by smtp{d,ctl} or mail after your change. Or were you going to commit that seperately? > > Eric. > > Index:

rpki-client vs expat API madness

So expat has a few options that changes the ABI / API of expat. One of them is XML_GetCurrentLineNumber() which returns a XML_Size which is typedef-ed to unsigend long or unsigned long long depending on the XML_LARGE_SIZE define. To work around this I just use a unsigned long long to store the

vmd(8): fix vmctl wait state corruption

vmd(8) users of tech@, NOTE: I have no intention to try to commit this prior to 6.9's release due to its complexity, but I didn't want to "wait" to solicit testers or potential feedback. I noticed recently that I could not have two vmctl(8) clients "wait" for the same vm to shutdown as one would

Re: smtpd: more unused code

On Mon, Apr 12, 2021 at 07:56:57AM -0400, Dave Voutila wrote: > > Eric Faurot writes: > > > Certificate verification is done by libtls. The former code is not used > > anymore and can be unplugged. > > Should cert.c be removed? I don't think it's used by smtp{d,ctl} or mail > after your change.

Re: iscsid/iscsictl: Introduce poll-and-wait delay during reload

On Sat, Mar 20, 2021 at 04:15:29PM -0400, Ashton Fagg wrote: > Hello. > > Pinging on this one hoping to get some feedback. I've reattached the > diff below. > Hi Ashton, I adjusted your diff a bit (mainly cleanup of spacing and other style changes). Please have a look. I think this version

Re: libressl pc files

On Mon, 12 Apr 2021 13:25:06 -0600, "Todd C. Miller" wrote: > This is a bit of a mess. LibreSSL portable puts the LibreSSL version > number in the pc files. In-tree LibreSSL uses 1.0.0 which is clearly > wrong--using SHLIB_VERSION_NUMBER for the version makes absolutely > no sense to me. The

Re: libressl pc files

[this is re: https://marc.info/?l=openbsd-tech=160673147428172=2] On 2021/04/12 13:25, Todd C. Miller wrote: > This is a bit of a mess. LibreSSL portable puts the LibreSSL version > number in the pc files. In-tree LibreSSL uses 1.0.0 which is clearly > wrong--using SHLIB_VERSION_NUMBER for the

fix diff3/merge for files lacking \n at EOF

Josh Rickmar discovered a bug in 'got cherrypick' where an error was raised even though the merge should have succeeded: got: unexpected end of file I have traced this back into OpenBSD's diff3(1) implementation. With the 3 attached files called a, b, and c (files a and b lack the

Re: libressl pc files

This is a bit of a mess. LibreSSL portable puts the LibreSSL version number in the pc files. In-tree LibreSSL uses 1.0.0 which is clearly wrong--using SHLIB_VERSION_NUMBER for the version makes absolutely no sense to me. The pc files used by OpenSSL also use the release version. The simplest

Re: rpki-client vs expat API madness

On Mon, Apr 12, 2021 at 10:25:35AM -0600, Theo de Raadt wrote: > > + line = XML_GetCurrentLineNumber(p); > > I think you can simplify your larger diff and avoid the temporary variable > by doing: > >warnx("%s: XML error at line %llu: %s", s->local, >

Re: rpki-client vs expat API madness

> + line = XML_GetCurrentLineNumber(p); I think you can simplify your larger diff and avoid the temporary variable by doing: warnx("%s: XML error at line %llu: %s", s->local, (unsigned long long)XML_GetCurrentLineNumber(p),

Re: tcpdump: fix XXX in fdata()

I apologize, I managed to slip in a syntax error. This reply has the missing close parenthesis. Index: usr.sbin/tcpdump/smbutil.c === RCS file: /cvs/src/usr.sbin/tcpdump/smbutil.c,v retrieving revision 1.10 diff -u -p -u -r1.10

tcpdump: fix XXX in fdata()

It appears that all the fdata() calls use fmt strings supplied at compile time so this patch makes all the same assumptions, the only change is that it uses the right functions for the job. Index: usr.sbin/tcpdump/smbutil.c ===

Re: fix diff3/merge for files lacking \n at EOF

On Mon, 12 Apr 2021 21:18:41 +0200, Stefan Sperling wrote: > The problem is that the code scanning a common chunk of lines doesn't > account for the possibility that EOF may occur before a final newline. > > This patch fixes the problem in all affected tools in the tree. OK? The return value of

Re: uvm_page_physload: use km_alloc(9)

On Mon, Mar 22, 2021 at 11:50:00AM +0100, Mark Kettenis wrote: > > Date: Mon, 22 Mar 2021 11:29:52 +0100 > > From: Martin Pieuchot > > > > Convert the last MI uvm_km_zalloc(9) to km_alloc(9), ok? > > Also needs some careful testing on multiple architectures. I did run both diffs through a full