hello all, OpenZFS 2.2.0 released, is the new feature intergrated witn zfs in illumos? thank you

Is it possible to run omnios in a vm on an Apple silicon mac?

Reliably i might add :)

elwisp with UTM x86 emulation, yes. reliability is another question. Unfortunately illumos kernel does not really behave too well with qemu (UTM is based on qemu).

i see

tsoome_: that's interesting, what makes it not play nicely with qemu?

Hm, I have OpenIndiana and OmniOS in Proxmox (so gotta be qemu on Linux, native CPUs though) which was an adventure to set up regarding supported virtual hardware for network and storage, but they chug along for a couple of years... decently enough for a build farm. Interactive use via VNC on one of those with a MATE desktop is a bit laggy...

Did anyone encounter issues with docbook recently? OpenIndiana/oi-userland #14559 bites me

...

aru I do not know what exactly, but I see random stuck early startup of the system. qemu monitor 'info registers' does show activity, but no progress on startup. Have not had enough time to investigate it properly. Even boot -k and sending nmi can end up with 'starting kmdb' message and no progress;)

on a side note: how much is illumos on ARM a thing? could that VM on Apple run with native CPU pass-through? ;)

anectodal point: both omnios and openindiana work well for me as VMs. qemu/kvm on debian linux.

a gentleman in other channel pointed out to using vmware driver (even if not presented as option by virt-manager) to get decent screen resolution

ditto that, also got vmware video for the desktop VM on proxmox

HDD and Ethernet seem to go well as virtio (or nvm passthrough in case of that desktop)

machine q35 and i440x both represented :)

Great tips

are there any illumos-based community build servers, or other recommendations for seeing when a large array of packages might introduce a breaking change? Somewhat related - anyone know if there are any public (and ideally free) CI runners for illumos, for instance - something useable from github actions?

In terms of validating say header or library changes like that, folks generally assist with that. Both in building say all of the OmniOS package sets and all of pkgsrc. Especially with pkgsrc that's ~10k packages which covers a fairly wide and diverse set.

rmustacc - that's good. maybe that resolves the issue i was thinking of but i'm not sure. What I imagine: for Rust, given a set of pinned packages - pull the latest version available, and run e.g. `cargo test` on each of them, and flag any regressions. Why I think this may be different from what you said is because I assume the OmniOs package sets aren't updated to the latest version without manual intervention (but maybe I'm wrong

I took the start of this as being does a change in illumos introduce a breaking change in the broader ecosystem.

for the rust coreutils library - i now have uucore build passing and all tests passing. but the larger coreutils library still has 73 failing tests hah. I know people aren't clamoring for that, but it would be nice to track regressions once all those are fixed (for instance)

Ah, you're looking for just normal CI of the project on an illumos based platform. Sorry, I misunderstood that initially.

yeah. that, and possibly just creating a meta project for the community where they can pin Rust libraries they want to track and have those built every so often. I know there's at least some interest in Rust on illumos

but also - it wouldn't necessarily need to be Rust specifc, that's just my current angle

at the end now I'm able to build gate on an a old machine that shutdown due thermal failure, just added some silver paste that I had remaining

I just needed to use smfgen, it was really painless, great stuff to create smf manifests