and now the 2023a TZ data is already obsoleted by 2023b, thanks to Lebanon adjusting it's DST switchover until after Ramadan

It keeps is on our toes! I have illumos 15510 (fenix) out for review - just running final tests before submitting the change later today.

FEATURE 15510: Update tzdata to 2023b (In Progress)

↳ illumos.org/issues/15510 | code.illumos.org/c/illumos-gate/+/2739

yeah, I saw that a few minutes later as I catch up on mail first thing this morning

get yourself a coffee.

in the thread under fosstodon.org/@cks⊙ms/110075273226149559 I mentioned that we're adding fsync() calls to useradd/groupadd/etc. but from another comment in that thread it sounds like maybe you just want to make them call the illumos librename

@alanc since you're here, dumb question. What man section is the Solaris `dd` command in?

dd(8)

Ahh, thank you.

One could make the case for that belonging in dd(1), but I figured it was inherited from SysV.

librename is great - I think rmustacc wanted to only have to work out the order of the hoops once!

You've essentially confirmed it, thanks!

interesting. FBSD has it in (1).

(Which is where I'd have also expected to see it.)

MacOS has it in (1), which was what prompted me to ask. At least one Linux has it in dd(1) as well.

CentOS Stream 8 has it in 1, so I presume all RHEL-derived ones do (but can't check).

danmcd: I (and I assume solaris), just rearrange sections, rather than judging if the sections things were in also were sensible.

Oh no arguments from me about THAT! dd moving out of 8 is it's own question, is all.

and I don't think _anyone_ bothered to fully line up the GNU manual pages

Heh heh heh.

so I think on (historical) solaris, and modern illumos OI, gdd(1) but dd(8)

Given ours/Solaris's lives in /usr/bin, one could make a move-out-of-8 argument as well, but again, that was not the point of the great manpage renumbering.

Not a hill I wanna die on, just one I wanna point out.

So rmustacc's improved i40e bits link-type bits are building.... I can run some errands in that 65min build window.

speaking of i40e.. i (finally) have some changes that will hopefully prevent the glacial dladm create-vnic issues you can hit with it w/ jumbo frames

if the internal smoke testing bears out, I'm going to see if I can get it up for external review since it'd be good to have since there's more i40e expertise in the wider community

jbk: infernal smoke testing would be more thorough

and perhaps appropriate

Oohhh jbk --> if you bring up a testing army, I'd LOVE for them to take shots at fenix illumos 13230 too

BUG 13230: i40e has duplicate traffic when used with bhyve/snoop running (New)

↳ illumos.org/issues/13230

danmcd: yeah, probably a SVR4ism, since SunOS 4.1.4 & earlier had man1/dd.1 and then Solaris 2.0 & later had it in section 1m

I don't see man pages in the SVR4 archives I have, but it appears to be in section 1M in the SVR3 archives

I'm pretty sure 1M etc came from SysV at some point in general

but I also seem to remember there was a lot of weirdness in the interim

before everyone agreed to just go back to what they did originally.

(except IBM I guess, they seem to still have non-numeric sections)

yeah, the 1M vs. 8 came from SysV - I was looking more at dd in 1 vs 1m/8

ah, yeah.

I'd be willing to describe it as "a mess" currently

dtrace(8) anyone?

svcs(1) & svcprop(1) vs. svccfg(8) and svcadm(8) [yes I know why, but still look in the wrong dir too often]

hmm...

it appears nvme_ioc_cmd() does not deal well with a timeout value of 0

(might be an issue for anyone that issues a pass-thru nvme ioctl)