toasterson (and others) - I might be able to start off with some light Rust work (maybe rewriting some Python in Rust, but could be something else). I know you are working on an IPS rewrite in Rust. I'm not very familiar with IPS but might be a good chance to learn more

(anything non-urgent as I have many claims on my time haha - thanks for your consideration and suggestions)

ips rewrite in rust? cool. I don't know much about ips' internals, but I do know some rust. If you need another set of eyes on the code, feel free to ping me

I notice there are quite a few python scripts in illumos-gate. Not sure how maintainers would feel about replacing those with Rust. It could speed things up in the build, especially if they were packaged separately (maybe as an IPS package?) Then again, maybe very little time is spent executing those scripts

Now that I say that, a separate IPS package is probably a bad idea.

Well, IPS itself is completely separate from the gate, both in terms of source and how it's packaged

Being separate, it would be pretty easy to drop in an alternate version and see how well it worked

I suspect significant speedups in the build require a more substantial rework

Right - I was referring to some helper scripts in gate. I realized that trying to sync up a separate package with gate would probably not be ideal. Instead, just having a cargo package to build those within gate would probably be better

Eg, unleashed cut gate builds from 40 minutes to 16

ptribble oh yes unleshead built pretty fast, but I think they removed and reorganized a lot of stuff.

Interesting - I hadn't heard of unleashed, but have been away from illumos near a decade. I'm sure you are right about my suggestion not speeding things up significantly. Was kind of looking for low hanging fruits. Even if those fruits have the caloric equivalent of lawn strawberries.

Does anyone here happen to have an illumos box with X11 running that could run "cargo test" for me from a git branch?

papertigers, sure

bbarker: ty! The commit in question: papertigers/cli-clipboard dbb5d46

just git clone; git checkout illumos; cargo test

papertigers, bebarker.notion.site/cli-clipboard-…2bebb44874f709ae340f431dd08ba?pvs=4

bbarker: sigh -- thanks

papertigers, sure, let me know if i can help again

bbarker: tbh I don't know if the x11 crate even supports illumos. A package I maintain in omnios-extra started depending on cli-clipboard and broke recent builds, but I will let you know if I need additional testing

papertigers: not sure how helpful the tests for x11-rs are, but the tests seem to pass for me

bbarker: what about these: github.com/quininer/x11-clipboard

papertigers, all tests good there

thanks... I will have to see why the cli-clipboard crate isn't happy with my change

not the easiest stacktrace for me sadly hah

papertigers - not sure what the nature of the Timeout error might be. wonder if it may be possible to insert some more debug info into your branch for now, or a debug branch

[illumos-gate] 15937 it is spelled default -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16013 remove all stauts -- Toomas Soome <tsoome⊙mc>

I migrated my laptop and want to passthru my wifi card to a bhyve vm. I did that on the old laptop. Now if I want to start the bhyve vm, I get: ERROR:root:Error b'bhyve: PCI device at 7 is not using the ppt driver\ndevice emulation initialization error: Device busy\n' (Arguments: to bhyve: -S -s 8,passthru,/dev/ppt0), pptadm list -a says: /dev/ppt0 8086 85 /pci@0,0/pci8086,1e12@1c,1/pci8086,1311@0

I think I had that error in the past already and somehow solved it...however I don't remember how :/

tsoome: for future typo fixes, it's probably not worth fixing non-uservisible stuff in contrib/ it's just another diff to carry.

unless pmooney says different about bhyve

If contrib/bhyve is tripping checks, then I would exclude it

The intent of that area (vs compat/bhyve) was to be able to copy headers/code with little-to-no modification

yeah, I just mentioned this because (for git reasons I don't want to consider) it made me merge a typo fix in the ksh93 release notes from 1999

oh and by the way...if I do pci passthru with bhyve, and I specify "pci slot 8" (-s 8,passthru) it complains about PCI device at 7. the number is always off from what I specify...I can't find a reason for that in the man pages...

bhyve is trivial, I can just commit it in fbsd;)

We aren't re-pulling those headers in contrib/bhyve unless we have a reason though

there was many spelling fixes done in fbsd lately too.

I was just saying if it's not user-visible, for a lot of that stuff it's just another source diff v. upstream

(if it is user visible obviously it needs fixed)

but I only noticed because git gets unpredictably tetchy sometimes

it is all public source, so anyone can see it. unless they have closed down github;)

there is a difference between spelling it "defult" in a usage message, and in a changelog entry from 1999 :)

but since ast has no upstream anymore, it's probably not going to be a big deal. I was more thinking of things that _do_ have one that we might have to merge again

github.com/ksh93/ksh/tree/dev/src/lib/libast could be your new ast upstream