xofyarg

> Going forward should only require explicitly enabling new things in order to use existing functionality in the event of show-stopping bugs, AFAIK, and none of those should really apply...

> What does "zfs get keystatus tank/backup/root" say? The key was available. > If you do a zfs send -w ... does that one mount That one mount, even created...

Regarding to the linked issue, I don't remember I ever sent the dataset in raw before(those were sent incrementally unencrypted). But simply creating a encrypted filesystem on 2.0.1 and then...

Sorry, I didn't mention the destination was under the same encryptionroot, so the created filesystem was encrypted.

It was 2.1.5. IIUC, the filesystem created from the old version(with some weird conditions) is somehow incompatible with current version. And the issue only affect "mounting", the data can be...

Quick update: ran into an issue likely related to #11679. Otherwise, the newly created filesystems by send | recv look good.

Yeah, it basically fixes the issue mentioned in #333, that when working with the out-of-tree libvterm source, this module [expects a statically linked library](https://github.com/akermu/emacs-libvterm/blob/a940dd2ee8a82684860e320c0f6d5e15d31d916f/CMakeLists.txt#L76). Guessing it used to work fine...

> Not sure if there will be issues after we merge a PR with a breaking change, though? I guess for people who use crates.io, it doesn't matter. And for...

I had the same question, and my colleague pointed me at this one: > ... the NSEC3 RR exists because it corresponds to an empty non-terminal, in which case the...

> Hopefully https://github.com/HaoboGu/rmk/pull/276 could solve it. I have a similar implementation locally, and it works pretty good so far. > `unprocessed_events.first()` could be used for peeking the next item in...