Changelog updates are now required in MRs by default. If there is a
match for "\<skip.\?changelog\>" in the commit message, this will be
ignored.
$CI_COMMIT_MESSAGE mangles newlines so it's not possible to require the
string to be on its own line, that means it would also trigger within a
wall of text, which makes it less obvious.
Also, I wasn't able to find a CI variable which has the ref of the
branch the MR is set against, to build a tree-ish than spans over the
whole MR and not just HEAD.
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This XEP is used to synchronize where each client has stopped reading a
conversation, so that we can e.g. stop displaying a notification when
the user has read this particular message on a different device.
This drastically improve the debuggability of the network parts, by
moving the task of encrypting/decrypting TLS packets from userland to
the kernel. This makes them appear in clear in strace as sendto() and
recvfrom().
I introduced a new tls-rust-ktls feature which depends on both rustls
and ktls, but isn’t enabled by default since it probably isn’t available
on every computer. It requires the tls kernel module to be loaded,
which then can offload encryption/decryption to dedicated hardware if
available.
I have tested this change on Linux 6.11 on a rk3588.
First switch to LazyLock from OnceLock, to simplify the code.
Then concatenate the colour reset escape code instead of using
format!(), since the vast majority of those strings have more capacity
than their length it will avoid a reallocation in most cases.
This allows to detect and handle dying streams without getting stuck
forever.
Timeouts are always wrong, though, so we put the burden of choosing the
right values (mostly) on the creator of a stream.
Without the early return in XmlStream::poll_next in case of the stream
footer, the read state gets recreated and the logic at the top of that
function to actually handle stream shutdown gracefully is never
triggered.
Also that logic was incorrect; the correct behaviour is to wait for the
true EOF.
The old error message was pointing at the `FromXml` / `AsXml` invocation
and not on the field which actually caused the problem. The new error
message points exactly at the type of the affected field.
This makes the stream resets a lot safer, by preventing the forbidden
send-read-reset combination of events: the reset function on the
responder side now takes the element to send right before the reset,
enforcing a send-reset pattern.