00:02:07 zfs send | zfs recv to fill the zvol on a pool that had lots of space, then set volsize, then patched it into the bhyve zone config with zonecfg, then booted 00:19:38 I'm building a fresh image, since there's some weirdness in the tests too, so I'll give both weirdnesses a try tomorrow. 08:49:33 ehh, pkg.oracle.com: Framework error: code: E_OPERATION_TIMEOUTED (28) reason: Operation too slow. Less than 1024 bytes/sec transferred the last 30 seconds 09:04:19 tsoome: indeed, Voyager is too far to upgrade it directly from oracle.com 09:04:56 I'm not on Voyager atm:D 19:19:41 jbk: it looks like cryptotest just failed on me because I already had dprov? that seems rude 19:20:07 (the second run worked, because cleanup removed the dprov I already had, which also seems rude) 19:25:41 sommerfeld: I saw your RFE for etags, you might also like https://gist.github.com/richlowe/c5ee6f81d72c9e65945a3a9151958175 (xref only supports real cscope not cscope-fast, but is easy enough to change the args around, the other tries to be smart) 19:41:22 richlowe: Thanks, I'll take a look. 19:42:09 One of the other things I'd like to share is a bringover_git for nightly. 20:17:19 i think that predates my work (not that i've done any crypto test work in several years) 20:19:12 i think i have some work to pull out the test data into separate files instead of a compiled .c file 20:19:27 that i'd need to finish up and throw up for review 20:19:28 but that's about it 20:20:02 oh, I thought you were mostly in there 20:20:17 i've done a fair amount of work in the past 20:20:27 to try to accompany the pkcs11 fixes i was doing 20:20:52 but i got essentially permanently blocked on fixing the outstanding issues there 20:21:24 so all that work has been stopped 20:28:51 jbk: the test data has already been pulled out of compiled C files 20:29:02 that was for the hash bits IIRC 20:29:11 i thought it was still there for the block ciphers 20:29:31 the format of the test vectors from NIST was slightly different I thought 20:30:26 (for block ciphers) 20:30:34 I guess those do remain 20:30:44 they were a rounding error compared to the hash tests 20:40:34 on an unrelated note.. is there anything that you can stick in a pipeline to throttle the output rate? 20:40:41 that works on illumos 20:44:53 mbuffer probably 20:45:30 yeah, mbuffer -r/-R 20:48:58 ahh ok 20:56:23 I do it sometimes to slow down my postgres backups, I'm pretty sure it works. 20:57:47 but I think it's fair to say nothing I've done/tried to do this week has _worked_, so maybe have bell book and candle ready 21:01:09 heh 21:03:03 i'll scrape up some chicken bones 21:48:38 tsoome: I'm getting tst.enum.d failures, I'm guessing that's something about your #15349? 21:48:51 types/tst.enum.d that is 21:49:12 dtrace: failed to compile script tst.enum.d: line 47: identifier redeclared: zero 22:16:48 looking at this more closely - how did this enum ever work? 22:17:15 (elements of my_enum2 all collide with my_enum) 22:34:59 hm 22:37:35 sigh. 22:39:05 obviously broken, but ... 22:41:10 oh well, obviously I have mixed it up... 22:43:16 fortunately, it is simple fix... 22:45:46 like this: https://code.illumos.org/c/illumos-gate/+/2654 22:45:47 → CODE REVIEW 2654: 15349 dtrace should accept comma after last item in enum (fix tst.enum.d) (NEW) | https://www.illumos.org/issues/15349 22:52:42 Sorry I missed this in code review..