| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reverts commit de5b2ef096cc03796398f7ca627ad5f4306aa065.
|
|
fzf: 0.47.0 -> 0.48.1
|
|
krita: wrap with plugins, krita-plugin-gmic init at 3.2.4.1
|
|
|
|
`fzf-share` was removed
|
|
This allows for correct highlighting and maybe future automatic
formatting. The AST was verified to work with nixfmt only.
|
|
This should help us with highlighting and future formatting.
|
|
doc: document publicly-known private key for darwin.linux-builder
|
|
|
|
|
|
|
|
At this point kernel.features is more of an implementation detail and
normal users should not come into contact with it.
|
|
Per RFC 9110, [section 8.8.1][1], different representations of the same
resource should have different Etags:
> A strong validator is unique across all versions of all
> representations associated with a particular resource over time.
> However, there is no implication of uniqueness across representations
> of different resources (i.e., the same strong validator might be in
> use for representations of multiple resources at the same time and
> does not imply that those representations are equivalent)
When serving statically compressed files (ie, when there is an existing
corresponding .gz/.br/etc. file on disk), Nginx sends the Etag marked
as strong. These tags should be different for each compressed format
(as shown in an explicit example in section [8.8.3.3][2] of the RFC).
Upstream Etags are composed of the file modification timestamp and
content length, and the latter generally changes between these
representations.
Previous implementation of Nix-specific Etags for things served from
store used the store hash. This is fine to share between different
files, but it becomes a problem for statically compressed versions of
the same file, as it means Nginx was serving different representations
of the same resource with the same Etag, marked as strong.
This patch addresses this by imitating the upstream Nginx behavior, and
appending the value of content length to the store hash.
[1]: https://www.rfc-editor.org/rfc/rfc9110.html#name-validator-fields
[2]:
https://www.rfc-editor.org/rfc/rfc9110.html#name-example-entity-tags-varying
|
|
This fixes the working directory for the suggested flake, as originally
suggested by @MaxDaten in:
https://github.com/NixOS/nixpkgs/issues/229542#issuecomment-1674886874
… and then amended by @Enzime in:
https://github.com/NixOS/nixpkgs/pull/248554#issuecomment-1676825733
|
|
The Nixpkgs documentation on the linux kernel builders focused on
using and extending kernels that were already packaged, but never
mentioned that it's possible to also build a kernel almost "from
scratch".
The NixOS documentation went a bit deeper on manual linux kernel
configs, but that information wasn't particularly NixOS-specific.
This commit consolidates the information related to building the
kernel on Nixpkgs's documentation, while keeping any additional
NixOS-specific information on NixOS's documentation.
An additional README.md was created for contributor-facing
documentation.
|
|
Using the script in maintainers/scripts/update-redirected-urls.sh
|
|
While the word 'simply' is usually added to encourage readers, it often has the
opposite effect and may even appear condescending, especially when the reader
runs into trouble trying to apply the suggestions from the documentation. It is
almost always an improvement to simply drop the word from the sentence.
(there are more possible improvements like this, we can apply those in separate
PRs)
|
|
|
|
|
|
|
|
|
|
|
