06:56:03 <jclulow> Alright, so: I have deployed Anubis in front of the bug tracker
06:56:18 <jclulow> Let me know if you have trouble getting to it
07:02:53 <wiedi> thanks, seems pretty fast now :)
07:04:50 <jclulow> hooray
07:05:02 <jclulow> I have attempted to make sure git-pbchk will be allowed thorugh
07:05:04 <jclulow> *through
08:18:49 <teutat3s> jclulow (LIBERA-IRC): anubs to the rescue. Thanks! 
08:19:06 <teutat3s> s/anubs/anubis/
09:16:21 <arekinath> may the jackal-eared girl preserve us
09:49:27 <gitomat> [illumos-gate] 17725 pcieadm could decode Virtio vendor-specific capabilities -- Andy Fiddaman <illumos⊙fn>
12:19:36 <Reinhilde> :o
17:36:38 <sommerfeld> jclulow: seems to be working.   I'm not seeing the anime interstitials that appear on other installations of anubis (and hope it stays that way in our installation...)
18:15:22 <jclulow> I think that will only show up if we have to ramp up the challenge complexity
18:15:39 <jclulow> Or obviously if you somehow trip the bot detection
18:24:52 <jclulow> fenix: illumos#17725
18:24:53 <fenix> FEATURE 17725: pcieadm could decode Virtio vendor-specific capabilities (Closed)
18:24:54 <fenix> ↳ https://www.illumos.org/issues/17725 | https://code.illumos.org/c/illumos-gate/+/4445
19:35:58 <gitomat> [illumos-gate] 17733 crypto-tests failures when run as non-root -- Gordon Ross <gwr⊙rc>
19:39:58 <richlowe> jclulow: heroic
21:01:31 <danmcd> Eeesh good catch @andyf on fenix illumos#17734
21:01:32 <fenix> BUG 17734: ZFS fsync can trigger ZIL transaction reordering and data corruption (In Progress)
21:01:32 <fenix> ↳ https://www.illumos.org/issues/17734
21:03:09 <danmcd> BTW for some values of Sun login IDs where it's `flNNNNN` (e.g. were I forced to use that back in the day it'd have been `dm30063`) I have data.
21:10:34 <richlowe> for all values in commit messages I have data too
21:10:38 <richlowe> would you like it dan?
21:11:12 <andyf> That one's taken a village over the past weeks. I only got involved today after it became clear it was likely to be something in ZFS, and colleagues presented a tidy reproducer.
21:11:12 <richlowe> I've been hesitant for other people for privacy reasons, but I know you...
21:19:20 <danmcd> Ack.
21:23:49 <tsoome>  /facepalm https://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/rcm_daemon/common/ibpart_rcm.c?r=aab83bb8#314
21:28:34 <jbk> doh!
21:51:10 <richlowe> based on the comment, they were trying for `ASSERT(node != NULL)`
22:02:26 <danmcd> Maybe ^K'd the assert before committing by accident?
22:53:56 <sommerfeld> andyf: I'm pretty sure I've seen the underlying failure mode (file corruption due to block write being reordered before a truncate) in a different contexts.  NFS, maybe?
23:50:42 <andyf> Could be. It's always going to be a bad idea. The ZFS ZIL has a handful of places this could happen now I'm looking at it, because it can switch between sync and async records. It's just probably not as bad for most things unless a truncation is involved.
23:50:53 <andyf> and of course you do need a ZIL replay..