12:34:26 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 12:35:11 (anything non-urgent as I have many claims on my time haha - thanks for your consideration and suggestions) 12:47:15 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 12:59:27 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 13:00:08 Now that I say that, a separate IPS package is probably a bad idea. 13:24:01 Well, IPS itself is completely separate from the gate, both in terms of source and how it's packaged 13:24:38 Being separate, it would be pretty easy to drop in an alternate version and see how well it worked 13:25:28 I suspect significant speedups in the build require a more substantial rework 13:25:36 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 13:26:10 Eg, unleashed cut gate builds from 40 minutes to 16 13:26:20 https://unleashed.31bits.net/releases/1.4/notes.txt 13:33:25 ptribble oh yes unleshead built pretty fast, but I think they removed and reorganized a lot of stuff. 13:35:58 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. 15:04:10 Does anyone here happen to have an illumos box with X11 running that could run "cargo test" for me from a git branch? 15:04:50 papertigers, sure 15:05:30 bbarker: ty! The commit in question: https://github.com/papertigers/cli-clipboard/commit/dbb5d462d6989a613e74bb5c7d69e9895dcd2625 15:05:44 just git clone; git checkout illumos; cargo test 15:11:47 papertigers, https://bebarker.notion.site/cli-clipboard-9b12bebb44874f709ae340f431dd08ba?pvs=4 15:13:26 bbarker: sigh -- thanks 15:28:37 papertigers, sure, let me know if i can help again 15:30:12 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 15:33:37 papertigers: not sure how helpful the tests for x11-rs are, but the tests seem to pass for me 15:34:35 bbarker: what about these: https://github.com/quininer/x11-clipboard 15:39:43 papertigers, all tests good there 15:40:38 thanks... I will have to see why the cli-clipboard crate isn't happy with my change 15:47:35 not the easiest stacktrace for me sadly hah 16:03:50 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 17:43:46 [illumos-gate] 15937 it is spelled default -- Toomas Soome 17:50:08 [illumos-gate] 16013 remove all stauts -- Toomas Soome 18:30:15 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 18:30:56 I think I had that error in the past already and somehow solved it...however I don't remember how :/ 20:53:31 tsoome: for future typo fixes, it's probably not worth fixing non-uservisible stuff in contrib/ it's just another diff to carry. 20:54:09 unless pmooney says different about bhyve 20:56:08 If contrib/bhyve is tripping checks, then I would exclude it 20:56:30 The intent of that area (vs compat/bhyve) was to be able to copy headers/code with little-to-no modification 21:01:43 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 21:11:31 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... 21:42:20 bhyve is trivial, I can just commit it in fbsd;) 21:46:48 We aren't re-pulling those headers in contrib/bhyve unless we have a reason though 21:50:08 there was many spelling fixes done in fbsd lately too. 21:51:17 I was just saying if it's not user-visible, for a lot of that stuff it's just another source diff v. upstream 21:51:26 (if it is user visible obviously it needs fixed) 21:51:40 but I only noticed because git gets unpredictably tetchy sometimes 21:53:07 it is all public source, so anyone can see it. unless they have closed down github;) 21:59:34 there is a difference between spelling it "defult" in a usage message, and in a changelog entry from 1999 :) 22:00:06 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 22:59:49 https://github.com/ksh93/ksh/tree/dev/src/lib/libast could be your new ast upstream