The two attributes being accessed here don't exist when calling though
flake-compat, so we need to handle that case by making the environment
variable unset if neither attribute exists.
Turns out fenix.packages.aarch64-linux.targets.x86_64-*.minimal.rustc
is an x86_64 compiler. The only component that you actually need to pull
from 'targets' for cross compilation is rust-std.
Because x86_64-unknown-linux-gnu is first in the target list, we were
getting x86 rustc and cargo binaries, making it impossible to compile
grapevine on an aarch64 host.
We were also missing aarch64-unknown-linux-gnu in the targets list,
which is used by the default package on a aarch64 host.
I like to put a bunch of untracked stuff in a /scratch directory for
each project, and then puth /scratch in my global gitignore. There are
usually some markdown notes files in here that I don't care about style
for. The previous markdownlint invokation didn't respect the global
gitignore, making local 'engage' runs kinda useless due to false
positives from the scratch dir.
Previously we required every alias in a canonical alias event sent by a
client to be valid, and would only validate local aliases. This
prevented clients from adding/removing canonical aliases if there were
existing remote or invalid aliases.
Previously, we would only attempt to validate the aliases in the event
content if we were able to parse the event, and would silently allow it
otherwise.
I think it's most important for people to read the "Chat with us", "Can
I use it?" and "Expectations management" sections, though I'm not sure
what the best ordering is. This is probably fine.
This is also a good spot to link to the pre-built binaries. And since I
did that, I can also remove the bit about not publishing binary builds
from the introduction section.
The previous logic would increment the backoff counter both when a
request actually fails and when we do not make a request because the
server was already in backoff. This lead to a positive feedback loop
where every request made while a server is in backoff increases the
backoff delay, making it impossible to recover from backoff unless the
entire backoff delay elapses with zero requests.
Failing to reset the backoff state resulted in a monotonically
increasing backoff delay. If a remote server was temporarily
unavailable, we would have a persistently increased rate of key query
failures until the backoff state was reset by a server restart. If
enough key queries were attempted while the remote was unavailable, it
can accumulate an arbitrarily long backoff delay and effectively block
all future key queries to this server.
This is pure code-motion, with no behavior changes. The new structure
will make it easier to fix the backoff behavior, and makes the code
somewhat less of a nightmare to follow.
This is okay because we only allow fast-forward merges, changes always
go through MRs, and MRs are subject to, e.g., the code quality checks.
This change is desirable because it should save some time and energy.
GitLab doesn't seem to have built-in support for this because of course
it doesn't.
To do this, we move the job scripts to a different file to make it
possible to share code between job scripts.
This way we don't have to be so careful about where we call `direnv
exec .` and can safely assume e.g. in scripts that we're always in the
direnv environment.
* Capitalize Conduit and Grapevine
* Replace a "Not" with "Note"
* Change a "Conduit 0.7.0" to "Conduit <0.8.0"
* Expand "db" to "database" and "database schema" as appropriate
This was based on the similar section in the hedgedoc. I dropped the bit
about grapevine users getting banned from the conduwuit rooms cause we
haven't heard about that happening for a while and the original case was
pretty unclear.
