i really need to yeet the rest of the perl stuff in the build (tools might be a bit longer)...

i know for me, like 90% of my build failures are update bumped perl minor version and I didn't notice until an hour later

For illumos builds on Helios we have a tool that generates the right environment file, which I think has helped a lot

(whether you delete the perl or not, I think it's valuable)

I thought marcel had tidied the perl thing to auto-sense

but fwiw, I use a general purpose environment that I've changed very very rarely

my last change was 18 months ago, before that it was 26 months ago

so if it's breaking _often_ I have no idea what you could be doing

well part of it was the VM runs bloody

so do I

so if you don't update it and then run onu, it first pulls in all the updates

otherwise I have an env files for various options that have the right flags for everything so I know what I should expect

but since it's based on the default env files

and also so I don't have to worry about 'well you did a bunch of stuff to your env file that was wrong....'

a useful trick there is just to source the normal one, and then override bits.

but those also unfortunately hard code the perl and python versions and java (though for python, I think it ignore the micro, so that's been less of an issue)

if anyone is following along and newer to this than jbk

Regardless of anything else, I finally migrated pretty much all of my .env files to auto-sense things like that

export PERL_VERSION=5.`perl -MConfig -e 'print $Config{PERL_VERSION}'`

well i made the stupid mistake of actually reading the env files

and modifying the values where it says 'modify these'

when in fact they then get overwritten 1000 lines later in the file

and get surprised

because my changes are lost...

Fair - downloads.omnios.org/env/build-gate-on-bloody.env is better.

which you find out an hour+ later

nahamu: I got a core with a conceptually hung tailscaled, but there are no smoking guns and no real idea what's up. all I can say is we're waiting to read the tun device and otherwise sleeping

(which is a bit annoying when you've only got a few hours to work on something and you've just lost over half of it fighting the build env)

nahamu: but with green threads I'm not even sure if that much from the core is actually logically true

(it wedged up between the first line i typed to jbk today and the second)

FYI: for CMake fans, I have filed gitlab.kitware.com/cmake/cmake/-/issues/26302

oh, that's going to break a lot of software

so I missed what that's in reference to jperkin

cmake?

yes, specifically widespread usage of 'if(CMAKE_SYSTEM_NAME MATCHES "SunOS")'

ah, yeah, that's rough

and also why an autoconf triple is a terrifying proposition

for right now, aarch64-unknown-solaris2.11 even

because `*-*-solaris2.*)`

jperkin: I think we have to do it though

I would love an IPD (on which I would try to collaborate)

perhaps of even wider scope

now that one of the larger problems we've had in the past has been solved

it's possible we could actually like, talk about the problem and what the solutions are

lol

Indeed

it would - in this context - probably also make sense to teach clang about illumos

I concur!

[illumos-gate] 16748 asy: support higher baud rates -- Hans Rosenfeld <rosenfeld⊙gho>