Yeah, so... the golang people completely changed their CI shit

I have unfortunately been too busy to "contribute to LUCI"

Though we should probably figure out how to get that done

It's super unfortunate that they've pushed this work onto maintainers

The old thing was working fine :/

github.com/illumos/illumos-gate/blo…boot/i386/installboot.c#L1176-L1192 this is confusing the hell out of me

if you run installboot and give it the device path of the EFI system partition -- which IS the boot partition -- it fails with this error

(for UEFI systems)

it wants the ZFS slice on the disk

Yes, problem is that we also want to install bios version, and unless there is a boot partition, we store gptzfsboot into zfs label (3.5MB reserved space).

tsoome_: how do I convince something to disassemble loader.sym?

gobjdump -d for example

oh, does that work on x86?

shit

.oO oops?

i really hope some day we can ditch all of this legacy stuff...

I'm beating my head against locales and C++ again (see illumos/gcc #56 ). Looks like gcc's libstdc++ makes use of an (undocumented?) glibc extension to newlocale() to construct composite locales -- caugt it passing as the 2nd argument of newlocale: "LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=C"

i want to have installboot install some additional files into the UEFI system partition for diagnostic/troubleshooting purposes

you'd think this should be easy

but all of the legacy stuff is making it way more complicated than it should be

q

sommerfeld: I feel like I have heard about composite locales, but I do not know where

and I didn't think they looked like that

do we have our own thing, too, maybe?

all I have to hand is that I was trying to get a UTF-8 locale without the awful date(1) output, not relevant bits to you :\

richlowe: we have our own undocumented extension which accepts "en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/C"

"composite" = "not all of LC_* set the same way"

ah ha, yes, that sounds familiar

I could tweak the libstdc++ code to use our syntax or I could tweak libc's newlocale to accept (but not generate) the LC_X=x;LC_Y=y form.

the latter is potentially more resilient to changes in the interface (copes better with disagreements about the right order of categories)

has anyone noticed lofi(?) performance on debug kernels being awful?

2.03GiB 0:02:57 [11.7MiB/s]

about that awful

ugh why does that ring a vague bell

I generally avoid running debug kernels in circumstances where I'd care about performance, but, wow. Seems like a tiny bit of profiling might point at the cpu sink though..

sometimes the circumstances of doing many things at once leave you here

and you'd hope it would be easy to trace, but it turns out to happen in massive stalls, there's nothing odd in that it _is_ sleeping, just (I think) how long