[illumos-gate] 15203 `pargs -e` doesn't work on processes stopped at exec-success -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 15214 SMB should allow 256 bit ciphers -- Alexander Stetsenko <alex.stetsenko⊙gc>

has anyone come across .fa (full archive) libraries yet? meson/qemu are starting to use them, and while binutils handles them ok our tooling doesn't

jperkin: what exactly are they

Meson again :(

[Anakin to Padme] Meson is a new build system. [Padme] It's better than autotools, isn't it?

jlevon: hard to say, binutils ar/nm suggest they are just regular archives, but there's obviously some difference in the binary format as our file/nm/ar/etc just say unknown file type

As somebody who has packaged quite a lot of software, meson is much worse to deal with than any of them

andyf: I'll see your meson and raise you scons, waf, gyp...

andyf: that's surprising. it's definitely the least worst to actually write/modify stuff in IMO

I rate those above meson, gyp in particular is pretty nice

waf was somewhat manageable. scons extremely slow

scons in particular was the absolute worst as it didn't think we were posix

except maybe, you know, makefiles.

gyp has the google in it

We seem to spend all of our time patching or updating meson, or working around things

I'd still advocate for throwing make out of posix

now that my namesake no longer can push for his crappy extensions...

meson has definitely been the one I've had to do the least to support, and I'm very anti-everything-not-autotools

has been pleasantly surprising how much just works, given there's a huge number of projects converting to it

The patches we have had to carry to meson itself have definitely reduced over time, but I still defer updating meson itself if I can

The different perspectives are interesting. I recently converted the omnios nss build to use gyp, and it was a really pleasant experience (despite having to file a couple of upstream bugs to get illumos properly supported)

I've only come across waf for ntpsec, but I don't remember that being a problem.

I'm generally coming from the side of having to come and fix something in a codebase/build tool I have zero experience in, so I need strong support for being able to grok things fast, decent build logs, and reasonably obvious ways of fixing things.

meson has good output logs (hi cmake!) and so far it's been relatively trivial to add the occasional workaround in a meson.build or change meson itself.

jlevon: us-central.manta.mnx.io/pkgsrc/public/tmp/libhwcore.fa is an offending file from the qemu build

Which qemu version is that?

macos file seems to know about it: 'libhwcore.fa: thin archive with 132 symbol entries'

andyf: 7.2.0

build:extra:% file qemu-7.2.0/build/libhwcore.fa

qemu-7.2.0/build/libhwcore.fa: current ar archive, not a dynamic executable or shared object

Oh, a thin archive

interesting

See log.omnios.org/oi-dev/2022-11-22#1669160164-459253

So if your meson is older than 0.64.1, that would explain it

I already patched that out in github.com/NetBSD/pkgsrc/blob/trunk…patch-mesonbuild_linkers_linkers.py but maybe it needs fixing elsewhere too now

anyway thanks for the hint, I'll go digging

alanc's patch was mesonbuild/meson #11050/files

we're on 1.0.1 so should include that

Or they broke it again..

ok I found the problem, qemu ships it's own copy of meson..

and I guess you don't see the same failure due to: 'ERROR: --python requires using QEMU's embedded Meson distribution, but it was not found.' when I tried deleting it

I have no idea why it works for us then

you don't appear to pass --python, at least if I'm looking in the right file

The build log shows us running our system meson though, which might be doing it

[3] --- configure (amd64)

Running: /usr/lib/python3.10/bin/meson setup

so I assume without --python it'll use the system meson

Lazy question: I'll go read the code if I have to, but does anyone know if port_getn returning EINTR might be returning valid events? E.g. If I requested a minimum of 2 events and specified a null timeout, could I get back EINTR and a single event?

(or even 2 events and a long timeout that hadn't expired)

the man page suggests that EINTR would not update nget and that I should assume that I got back no valid events.

But I do wonder what would happen to a thread waiting indefinitely for two events where one had already been generated... is it impossible for the call to be interrupted at that point??

I have a similar question too about "brain-damaged OS bug"; it's when read(2) return -1 with errno == 0

I saw it 3 times in xorg, mouse & keyboard modules

It is possible that it has not been compiled with _TS_ERRNO

If you don't do that (or -D_REENTRANT), then in a multi-threaded app you can see things like that (denk)

I unedstand it now, thanks

nahamu: I don't believe that if you get EINTR it'll return with fewer evens and you have to check it.

*events

rmustacc: Making sure I understood: So I can trust the man page that if I get EINTR I got back no events and can just try again?

I believe so.

That's what a ~5 min read of code led me to think.

But it's always possible bugs exist!

Thank you for taking the time to look at that for me!

nahamu: It might be worth filing a bug about clarifying the language in the man page

I think it's fine. Prior instances of code I've written suggest I used to understand how things work.

I mean, if it lead to asking about it on IRC, or potentially going code spelunking, that seems like we could provide more detail

I'll dig up my credentials and file something.

up to you

I often find myself writing comments/docs for the purpose of helping future-me

I have added examples to man pages just to save me from having to puzzle out how to do something once again that I only do once every year or two when someone asks how to do it

pmooney: illumos.org/issues/15482

→ BUG 15482: PORT_GET(3C) could be clearer about port_getn and EINTR (New)

nahamu: thanks!

I can take a hint if it's made twice. :-P