Re: Doubts about the successors of OpenBSD leadership and development

[Otto Moerbeek]

On Tue, Jul 11, 2017 at 06:54:32AM +0200, Michele Curti wrote:

> On Mon, Jul 10, 2017 at 11:16:36PM +0200, Stefan Sperling wrote:
> > On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote:
> > > Who will succeed Theo de Raadt in the leadership and development of 
> > > OpenBSD?
> >  
> > Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and
> > development of OpenBSD: 
> > http://marc.info/?l=openbsd-misc=137609553004700=2
> >
> 
> Obviously a RAIT 1 (Redundant Array of Independent Theos).

Originally, the "I" was for "inexpensive" I always learned.

When RAID started to become more common, it took only a short time for
disk vendors to start creating expensive special RAID versions of
their disks having a long mean time between failure. Sending somebody
to a data center to swap disks does cost lot indeed. 

Having hot standby's is vital...

-Otto

Re: Doubts about the successors of OpenBSD leadership and development

[Michele Curti]

On Mon, Jul 10, 2017 at 11:16:36PM +0200, Stefan Sperling wrote:
> On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote:
> > Who will succeed Theo de Raadt in the leadership and development of OpenBSD?
>  
> Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and
> development of OpenBSD: http://marc.info/?l=openbsd-misc=137609553004700=2
>

Obviously a RAIT 1 (Redundant Array of Independent Theos).

--
Michele

Re: KARL not sending email?

[jungle boogie]

Hi Theo,
On 07/10/2017 09:24 PM, Theo Buehler wrote:

On Mon, Jul 10, 2017 at 07:44:19PM -0700, jungle boogie wrote:

Hi All,

I just updated from the 6th of July snapshot to the 10th of July.
When I logged in and check the mail, I didn't see a message advising a new
kernel link. Between the 6th and 10th I rebooted my machine many times and
didn't see the mail.

Are the mails no longer expected? How do I verify the kernel re-linking is
actually in place?


The mails were replaced with syslog in etc/rc -r1.507 once we were
confident enough that it works as expected. You'll find
'Kernel relinking done' notices in your /var/log/messages. In case an
error occurs, it will additionally be logged to the console.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc#rev1.507




Awesome! Sorry to have missed this commit.
As expected, the linking is happening without issue:
/etc/rc: kernel relinking done

Re: KARL not sending email?

[Theo Buehler]

On Mon, Jul 10, 2017 at 07:44:19PM -0700, jungle boogie wrote:
> Hi All,
> 
> I just updated from the 6th of July snapshot to the 10th of July.
> When I logged in and check the mail, I didn't see a message advising a new
> kernel link. Between the 6th and 10th I rebooted my machine many times and
> didn't see the mail.
> 
> Are the mails no longer expected? How do I verify the kernel re-linking is
> actually in place?

The mails were replaced with syslog in etc/rc -r1.507 once we were
confident enough that it works as expected. You'll find
'Kernel relinking done' notices in your /var/log/messages. In case an
error occurs, it will additionally be logged to the console.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc#rev1.507

KARL not sending email?

[jungle boogie]

Hi All,

I just updated from the 6th of July snapshot to the 10th of July.
When I logged in and check the mail, I didn't see a message advising a 
new kernel link. Between the 6th and 10th I rebooted my machine many 
times and didn't see the mail.


Are the mails no longer expected? How do I verify the kernel re-linking 
is actually in place?


Other than than, I don't have any issues with my system.


dmesg:
OpenBSD 6.1-current (GENERIC.MP) #94: Mon Jul 10 18:20:35 MDT 2017 



dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP 


real mem = 3194490880 (3046MB)
avail mem = 3091947520 (2948MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root 


bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf6e60 (62 entries)
bios0: vendor Dell Inc. version "A07" date 12/18/2006
bios0: Dell Inc. Latitude D620 


acpi0 at bios0: rev 0
acpi0: TCPA checksum error 

acpi0: sleep states S0 S3 S4 S5 

acpi0: tables DSDT FACP HPET APIC ASF! MCFG SLIC TCPA SSDT 

acpi0: wakeup devices LID_(S3) PBTN(S4) PCI0(S5) USB0(S0) USB1(S0) 
USB2(S0) USB3(S0) EHCI(S0) AZAL(S3) PCIE(S4) RP01(S3) RP02(S4) NIC_(S5) 
RP04(S3) RP05(S3) RP06(S3) 

acpitimer0 at acpi0: 3579545 Hz, 24 bits 


acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat 


cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1997.64 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR 


cpu0: 4MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE 


cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1997.33 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF,SENSOR 


cpu1: 4MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins 


acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0) 


acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 3 (PCIE) 

acpiprt3 at acpi0: bus 11 (RP01) 


acpiprt4 at acpi0: bus 12 (RP02)
acpiprt5 at acpi0: bus 9 (PXP0) 


acpiprt6 at acpi0: bus -1 (RP04)
acpiprt7 at acpi0: bus -1 (RP05) 


acpiprt8 at acpi0: bus -1 (RP06)
acpicpu0 at acpi0: !C3(100@57 io@0x1016), !C2(500@1 io@0x1014), 
C1(1000@1 halt), PSS
acpicpu1 at acpi0: !C3(100@57 io@0x1016), !C2(500@1 io@0x1014), 
C1(1000@1 halt), PSS
acpitz0 at acpi0: critical temperature is 126 degC 


"*pnp0c14" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpibat0 at acpi0: BAT0 model "DELL J825J8" serial 1093 type LION oem 
"Panasonic"

acpibat1 at acpi0: BAT1 not present
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN
"PNP0F13" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_ 

acpivideo1 at acpi0: VID_ 

acpivideo2 at acpi0: VID2 

cpu0: Enhanced SpeedStep 1997 MHz: speeds: 2000, 1667, 1333, 1000 MHz 


pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
acpimcfg0 at acpi0 addr 0xf000, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 3 (PCIE) 


acpiprt3 at acpi0: bus 11 (RP01)
acpiprt4 at acpi0: bus 12 (RP02)
acpiprt5 at acpi0: bus 9 (PXP0) 


acpiprt6 at acpi0: bus -1 (RP04)
acpiprt7 at acpi0: bus -1 (RP05) 

acpiprt8 at acpi0: bus -1 (RP06) 

acpicpu0 at acpi0: !C3(100@57 io@0x1016), !C2(500@1 io@0x1014), 
C1(1000@1 halt), PSS
acpicpu1 at acpi0: !C3(100@57 io@0x1016), !C2(500@1 io@0x1014), 
C1(1000@1 halt), PSS
acpitz0 at acpi0: critical temperature is 126 degC 


"*pnp0c14" at acpi0 not configured
acpiac0 at acpi0: AC unit online 

acpibat0 at acpi0: BAT0 model "DELL J825J8" serial 1093 type LION oem 
"Panasonic"

acpibat1 at acpi0: BAT1 not present
acpibtn0 at acpi0: LID_ 


acpibtn1 at acpi0: PBTN
acpibtn2 at acpi0: SBTN 


"PNP0F13" at acpi0 not configured
"PNP0303" at acpi0 not configured
"PNP0501" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
acpivideo1 at acpi0: VID_
acpivideo2 at acpi0: VID2
cpu0: Enhanced SpeedStep 1997 MHz: speeds: 2000, 1667, 1333, 1000 MHz 


pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82945GM Host" rev 0x03
inteldrm0 at pci0 dev 2 function 0 "Intel 82945GM Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16

Re: Pq rendering in ports(7)

[Ingo Schwarze]

Hi Jan,

Jan Stary wrote on Mon, Jul 10, 2017 at 05:57:08PM +0200:

> This is how ports.7 is rendered on my 6.1-current:
> 
>  For more information about using ports, see The OpenBSD Ports System (
>  https://www.openbsd.org/faq/faq15.html#Ports
>  ).For information about creating new ports, see the OpenBSD 
> Porter's
>  Handbook (
>  https://www.openbsd.org/faq/ports/
>  ).

That is much better than what groff renders, which is:

 For more information about using ports, see The OpenBSD Ports System (
 For information about creating new ports, see the
 OpenBSD https://www.openbsd.org/faq/faq15.html#Ports).  Porter's Handbook
 (

 For a detailed description of the build process, see
 https://www.openbsd.org/faq/ports/).

The groff rendering is completely broken, the mandoc rendering is much
better...

> The code snippet is
> 
>   .Pp
>   For more information about using ports, see
>   The
>   .Ox
>   Ports System
>   .Pq Lk https://www.openbsd.org/faq/faq15.html#Ports .
>   For information about creating new ports, see
>   the
>   .Ox
>   Porter's Handbook
>   .Pq Lk https://www.openbsd.org/faq/ports/ .

 ... so that mdoc(7) source code is not portable.

Maybe mandoc should warn about the portability issue?  Possibly,
but i would have to understand what exactly is broken in groff, so
what the permissible syntax is.  Or even better, we should fix groff?
That may be hard.

> The Pq rendering doesn't seem right: in the first case,
> the whole "( http:/// )" would fit nicely on the second line;
> in the second case, it would in fact fit nicely on the same line
> - the breaks after the '(' and before the ')' seem superfluous.

In groff, there is a length threshold.  Shorter links are rendered
inline, longer ones in what resembles a .D1 display.  That is not
completely unreasonable, so mandoc should follow.  I recently did
quite some work on .Lk rendering, and most valid constructs - i.e.
those rendering reasonably with groff - now render identically with
groff and mandoc.  There may still be bugs, of course.  At some
point, i got tired of how complicated this macro is to implement
and stopped digging for more edge cases.

Note that the .Pq is *outside* the .Lk, so it is logical that the
parentheses appear *outside* the display.  If you want the parentheses
inside the display, you might feel tempted to write something like

For more information about using ports, see
The
.Ox
Ports System
.Lk ( https://www.openbsd.org/faq/faq15.html#Ports ) .
For information about creating new ports, see
the
.Ox
Porter's Handbook
.Lk ( https://www.openbsd.org/faq/ports/ ) .

But that also breaks with groff:

 For more information about using ports, see The OpenBSD Ports System
 https://www.openbsd.org/faq/faq15.html#Ports: (). For information about
 creating new ports, see the OpenBSD Porter's Handbook
 https://www.openbsd.org/faq/ports/: ().

Since leading opening delimiters fail with groff, i was lazy and did
not implement keeping them in scope in mandoc either, but the mandoc
rendering is still better than the groff rendering:

 For more information about using ports, see The OpenBSD Ports System (
   https://www.openbsd.org/faq/faq15.html#Ports).
 For information about creating new ports, see the OpenBSD Porter's
 Handbook (
   https://www.openbsd.org/faq/ports/).


The .Lk macro is relatively young.  If i read the source history
correctly, it was added as part of the big groff-1.17 mdoc rewrite
in 2000.  Lk is more fragile than most other mdoc(7) macros.
Probably, some work should be done to make the implementation more
robust or at least to document the valid syntax more strictly.  The
current groff implementation looks rather sloppy to me.  I already
got two improvements committed to groff back in April 2017, but the
situation with .Lk is still far from satisfactory.


All that said, see below for what i just committed to improve the
quality and in particular the portability of the manual, using the
standard idiom rather than some hand-rolled approach.

Yours,
  Ingo



CVSROOT:/cvs
Module name:src
Changes by: schwa...@cvs.openbsd.org2017/07/10 16:48:00

Modified files:
share/man/man7 : ports.7 

Log message:
Fix non-portable .Lk usage that results in complete garbage with groff
and looks better, but still not good with mandoc.
Issue pointed out by Jan Stary .


Index: ports.7
===
RCS file: /cvs/src/share/man/man7/ports.7,v
retrieving revision 1.112
diff -u -r1.112 ports.7
--- ports.7 28 Jun 2017 10:24:23 -  1.112
+++ ports.7 10 Jul 2017 22:43:40 -
@@ -60,15 +60,9 @@
 to install the application.
 .Pp
 For more information about using ports, see
-The
-.Ox
-Ports System
-.Pq Lk 

Re: Doubts about the successors of OpenBSD leadership and development

[Steve Shockley]

On 7/10/2017 5:53 PM, Raul Miller wrote:

On Mon, Jul 10, 2017 at 5:04 PM, SOUL_OF_ROOT 55  wrote:

Theo de Raadt no responds to me private message since I told him that I do
not understand English.


If you told him that in english, I can imagine why.


Perhaps his English is mode 0266.

Re: Doubts about the successors of OpenBSD leadership and development

[Adam Thompson]

> From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of 
> Stefan Sperling
> Sent: July 10, 2017 16:17
> Subject: Re: Doubts about the successors of OpenBSD leadership and development
>
> Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership
> and development of OpenBSD: 
> http://marc.info/?l=openbsd-misc=137609553004700=2

I had forgotten about that old message :-).  Thank you for reminding us!

FYI, Anatolian Shepherd dogs (the Turkish national dog, IIRC) are extremely 
beautiful dogs (IMHO), and very nice, gentle and friendly, as a rule, unless 
they think you're threatening whatever they're protecting.  In which case 
there's no need for an entire group of them to kill Theo, one dog will likely 
be more than sufficient, regardless of how fit Theo may or may not be at that 
point in time.

Since we must, of course, take all statements from Theo literally (otherwise 
what kind of a cult are we?!?!), this does beg the question of what happens if 
he gets attacked by a group of dogs somewhere *other* than central Turkey.

If the project were based out of the US, the solution would be obvious: have 
Theo go armed at all times.  But since it's Canadian... hmm.  If we say he can 
only leave the country protected by one of our submarines, he'll - effectively 
- be protected, since none of them can actually go anywhere most of the time.



-Adam

Re: Doubts about the successors of OpenBSD leadership and development

[Raul Miller]

On Mon, Jul 10, 2017 at 5:04 PM, SOUL_OF_ROOT 55  wrote:
> Theo de Raadt no responds to me private message since I told him that I do
> not understand English.

If you told him that in english, I can imagine why.

(You effectively said that you do not know what you are saying - which
makes any response stupid. Including this one.)

-- 
Raul

Re: Doubts about the successors of OpenBSD leadership and development

[Stefan Sperling]

On Mon, Jul 10, 2017 at 06:04:53PM -0300, SOUL_OF_ROOT 55 wrote:
> Who will succeed Theo de Raadt in the leadership and development of OpenBSD?
 
Obviously, Theo de Raadt will succeed Theo de Raadt in the leadership and
development of OpenBSD: http://marc.info/?l=openbsd-misc=137609553004700=2

Doubts about the successors of OpenBSD leadership and development

[SOUL_OF_ROOT 55]

Who will succeed Theo de Raadt in the leadership and development of OpenBSD?

Can I succeed Theo de Raadt in the leadership and development of OpenBSD?

Theo de Raadt no responds to me private message since I told him that I do
not understand English.

Re: vio(4) stops working with debian 9.0 qemu-2.8+dfsg-6

[Mike Larkin]

On Mon, Jul 10, 2017 at 10:22:06PM +0200, Stefan Fritsch wrote:
> On Saturday, 8 July 2017 14:58:59 CEST Stefan Fritsch wrote:
> > A difference between i386 and amd64 is that on amd64, openbsd uses MSI-X for
> > virtio. Maybe legacy interrupts are broken with vhost-net. This needs some
> > more debugging. But its either a bug in qemu or in the linux kernel, not in
> > openbsd.
> 
> It's also broken with amd64 if MSI-X is disabled.
> 
> It's fixed in qemu 2.9. Debian bug report: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867978
> 
> Cheers,
> Stefan
> 

Thanks for tracking this down, Stefan!

-ml

Re: vio(4) stops working with debian 9.0 qemu-2.8+dfsg-6

[Stefan Fritsch]

On Saturday, 8 July 2017 14:58:59 CEST Stefan Fritsch wrote:
> A difference between i386 and amd64 is that on amd64, openbsd uses MSI-X for
> virtio. Maybe legacy interrupts are broken with vhost-net. This needs some
> more debugging. But its either a bug in qemu or in the linux kernel, not in
> openbsd.

It's also broken with amd64 if MSI-X is disabled.

It's fixed in qemu 2.9. Debian bug report: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867978

Cheers,
Stefan

Re: xntp mlockall issue patched yet?

[Christian Weisgerber]

On 2017-07-07, Kaya Saman  wrote:

>>> ntpd 4.2.8p10@1.3728-o Fri Jun  2 02:18:56 UTC 2017 (1): Starting
>
> The exact problem is that the service doesn't start... I have disabled 
> the ntpd from base in rc.conf then execute the rc.d script and no 
> service?? - just the error above.
>
> The service is added in rc.conf.local as such:
>
> xntpd=YES
> xntpd_flags=""

That's not the way xntpd is enabled.  You may want to use rcctl(8):

# rcctl stop ntpd
ntpd(ok)
# rcctl disable ntpd
# rcctl enable xntpd
# rcctl start xntpd
xntpd(ok)

The relevant lines in /etc/rc.conf.local end up being this:

ntpd_flags=NO
pkg_scripts=xntpd

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Pq rendering in ports(7)

[Jan Stary]

This is how ports.7 is rendered on my 6.1-current:

 For more information about using ports, see The OpenBSD Ports System (
   https://www.openbsd.org/faq/faq15.html#Ports
 ).  For information about creating new ports, see the OpenBSD Porter's
 Handbook (
   https://www.openbsd.org/faq/ports/
 ).

The code snippet is

.Pp
For more information about using ports, see
The
.Ox
Ports System
.Pq Lk https://www.openbsd.org/faq/faq15.html#Ports .
For information about creating new ports, see
the
.Ox
Porter's Handbook
.Pq Lk https://www.openbsd.org/faq/ports/ .

The Pq rendering doesn't seem right: in the first case,
the whole "( http:/// )" would fit nicely on the second line;
in the second case, it would in fact fit nicely on the same line
- the breaks after the '(' and before the ')' seem superfluous.

Jan

Re: FTP during install not working

[Stuart Henderson]

On 2017-07-10, Florian Viehweger  wrote:
>> I don't think it's really documented anywhere prominent, an errata
>> would be the usual place for something like this but they aren't
>> usually done without a code patch that can be applied..
>
> I've also stumbled across it. If an errata is not in real prospect,
> maybe a little notice in the upcoming 6.2 documentation?

It won't affect 6.2 as the problem was fixed after 6.1 release
was tagged.

Re: FTP during install not working

[Florian Viehweger]

> I don't think it's really documented anywhere prominent, an errata
> would be the usual place for something like this but they aren't
> usually done without a code patch that can be applied..

I've also stumbled across it. If an errata is not in real prospect,
maybe a little notice in the upcoming 6.2 documentation?

-- 
greetings,

Florian Viehweger

Re: FTP during install not working

[Stuart Henderson]

On 2017-07-07, Thomas Smith  wrote:
>> There was an installer bug in 6.1 resulting in the wrong path getting
>> written to installurl if you entered the mirror URL manually (this has
>> since been fixed). What you did (i.e. editing the file to remove 6.1)
>> is the the correct workaround.
>
> Understood. My apologies for posting this to the list--I should've
> checked it first instead of assuming it was part of the same problem.

I don't think it's really documented anywhere prominent, an errata would be
the usual place for something like this but they aren't usually done without a
code patch that can be applied..

Re: openldap port mdb support

[Stuart Henderson]

On 2017-07-10, Paul B. Henson  wrote:
> mdb has been disabled in the openldap port since it looks like
> 2015/02/16, I was wondering if anyone has tried it since then to see if
> maybe the issues with it have been resolved? The other backends are
> deprecated upstream, it would be nice to get mdb working under openbsd.
>
> I'm going to try enabling it and running through the tests and see how
> things turn out but I was just curious if anyone else had worked with it
> in the past couple of years.
>
> Thanks...
>
>

Feel free to try it, I believe the required patch to force MDB_WRITEMAP
is still in there..but I don't think there were any major changes upstream
since the last attempt so I wouldn't hold out too much hope for it working
straight off.

(Without MDB_WRITEMAP, mdb assumes mmap and file access can be intermixed
without syncs, which isn't the case on OpenBSD).

Re: A question of lock usage in OpenBSD kernel code

[Stuart Henderson]

The other answers you've had are good, just a couple of extras:

On 2017-07-07, J Doe  wrote:
> Ok, thank you for clarifying that for me. I will proceed with
> development in C. As an aside - do OpenBSD developers track with the
> latest standard (C11), or is another standard preferred ?

Compilers are currently GCC 4.2.1 and clang 4.0.0, so code needs to work
with both of those. OpenBSD runs on strict-alignment architectures, BE and
LE, signed vs. unsigned char arches, and different stack directions, so
portability is important.

> Ok. I had something like style(9) (https://man.openbsd.org/style.9)
> in mind, but of course: 1) It is the kernel style guide, not user land

It's used for both kernel and user land. Not absolutely strictly, but
shouldn't go too far from it. (Also generally local style in a particular
part of the tree should be respected).

openldap port mdb support

[Paul B. Henson]

mdb has been disabled in the openldap port since it looks like
2015/02/16, I was wondering if anyone has tried it since then to see if
maybe the issues with it have been resolved? The other backends are
deprecated upstream, it would be nice to get mdb working under openbsd.

I'm going to try enabling it and running through the tests and see how
things turn out but I was just curious if anyone else had worked with it
in the past couple of years.

Thanks...