02:55:07 [illumos-gate] 15203 `pargs -e` doesn't work on processes stopped at exec-success -- Robert Mustacchi 09:52:54 [illumos-gate] 15214 SMB should allow 256 bit ciphers -- Alexander Stetsenko 10:25:44 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 10:35:43 jperkin: what exactly are they 10:39:52 Meson again :( 10:41:30 [Anakin to Padme] Meson is a new build system. [Padme] It's better than autotools, isn't it? 10:42:04 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 10:42:12 As somebody who has packaged quite a lot of software, meson is much worse to deal with than any of them 10:42:33 andyf: I'll see your meson and raise you scons, waf, gyp... 10:42:57 andyf: that's surprising. it's definitely the least worst to actually write/modify stuff in IMO 10:42:59 I rate those above meson, gyp in particular is pretty nice 10:43:00 waf was somewhat manageable. scons extremely slow 10:43:00 scons in particular was the absolute worst as it didn't think we were posix 10:43:05 except maybe, you know, makefiles. 10:43:05 gyp has the google in it 10:43:28 We seem to spend all of our time patching or updating meson, or working around things 10:43:34 I'd still advocate for throwing make out of posix 10:43:58 now that my namesake no longer can push for his crappy extensions... 10:44:00 meson has definitely been the one I've had to do the least to support, and I'm very anti-everything-not-autotools 10:45:16 has been pleasantly surprising how much just works, given there's a huge number of projects converting to it 10:46:30 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 10:47:11 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) 10:47:38 I've only come across waf for ntpsec, but I don't remember that being a problem. 10:49:36 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. 10:54:06 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. 10:58:20 jlevon: https://us-central.manta.mnx.io/pkgsrc/public/tmp/libhwcore.fa is an offending file from the qemu build 10:59:22 Which qemu version is that? 10:59:39 macos file seems to know about it: 'libhwcore.fa: thin archive with 132 symbol entries' 10:59:45 andyf: 7.2.0 10:59:57 build:extra:% file qemu-7.2.0/build/libhwcore.fa 10:59:57 qemu-7.2.0/build/libhwcore.fa: current ar archive, not a dynamic executable or shared object 11:00:03 Oh, a thin archive 11:00:14 interesting 11:00:30 See https://log.omnios.org/oi-dev/2022-11-22#1669160164-459253 11:01:15 So if your meson is older than 0.64.1, that would explain it 11:01:46 I already patched that out in https://github.com/NetBSD/pkgsrc/blob/trunk/devel/meson/patches/patch-mesonbuild_linkers_linkers.py but maybe it needs fixing elsewhere too now 11:02:09 anyway thanks for the hint, I'll go digging 11:03:33 alanc's patch was https://github.com/mesonbuild/meson/pull/11050/files 11:05:01 we're on 1.0.1 so should include that 11:06:23 Or they broke it again.. 11:11:49 ok I found the problem, qemu ships it's own copy of meson.. 11:12:12 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 11:14:03 I have no idea why it works for us then 11:14:51 you don't appear to pass --python, at least if I'm looking in the right file 11:15:00 The build log shows us running our system meson though, which might be doing it 11:15:02 [3] --- configure (amd64) 11:15:02 Running: /usr/lib/python3.10/bin/meson setup 11:15:27 so I assume without --python it'll use the system meson 17:29:14 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? 17:33:34 (or even 2 events and a long timeout that hadn't expired) 17:37:39 the man page suggests that EINTR would not update nget and that I should assume that I got back no valid events. 17:39:47 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?? 17:44:33 I have a similar question too about "brain-damaged OS bug"; it's when read(2) return -1 with errno == 0 17:45:12 I saw it 3 times in xorg, mouse & keyboard modules 17:48:50 It is possible that it has not been compiled with _TS_ERRNO 17:49:43 If you don't do that (or -D_REENTRANT), then in a multi-threaded app you can see things like that (denk) 17:50:52 I unedstand it now, thanks 17:52:47 nahamu: I don't believe that if you get EINTR it'll return with fewer evens and you have to check it. 17:52:53 *events 17:53:38 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? 17:56:22 I believe so. 17:56:36 That's what a ~5 min read of code led me to think. 17:56:46 But it's always possible bugs exist! 17:56:49 Thank you for taking the time to look at that for me! 19:19:10 nahamu: It might be worth filing a bug about clarifying the language in the man page 19:20:06 I think it's fine. Prior instances of code I've written suggest I used to understand how things work. 19:23:26 I mean, if it lead to asking about it on IRC, or potentially going code spelunking, that seems like we could provide more detail 19:23:28 * pmooney shrugs 19:23:56 I'll dig up my credentials and file something. 19:24:49 up to you 19:25:11 I often find myself writing comments/docs for the purpose of helping future-me 19:26:58 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 19:33:40 pmooney: https://www.illumos.org/issues/15482 19:33:42 → BUG 15482: PORT_GET(3C) could be clearer about port_getn and EINTR (New) 19:41:57 nahamu: thanks! 19:43:22 I can take a hint if it's made twice. :-P