... bumping these in the same commit to avoid double-recompilation of
Emacs stuff.
Change-Id: Ieab114115b788c36e9d42246445cf17b960c11de
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3741
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This will also be used for the TVL blog, with status updates of
projects like Tvix.
Note that while this commit evaluates, there are still some things
specific to my blog in this code which I'll untangle in a future commit.
Change-Id: If59431161b165d7249cbb856073a4cae84a1bfbf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3732
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
When the system is set to dark mode, this is detected through
prefers-color-scheme and the color scheme is adjusted accordingly. This
fixes#18.
The colors are set using CSS variables on the body that are overrridden
based on the current color scheme.
Change-Id: Id2f95dee4d6968e1b62ce37534f623e489fabde4
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3722
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
Reviewed-by: sterni <sternenseemann@systemli.org>
The C code from which this is translated uses sentinel values for
various things, this commit replaces them with standard Rust types
instead (amongst a bunch of other small improvements).
Change-Id: I892811a7afebb5a0f3b825824fc493ab0b399e44
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3735
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Since this code is essentially a fairly plain translation from C, it
is a bit confusing to deal with the original untyped code. This is an
attempt to try and clean some of it up.
Change-Id: Icd21f531932e1a811c0d6dbf2e9acba61ca9c45d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3734
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
This was supposed to be a new patchset of the previous commit, but due
to ??? the change became submittable in between patchsets and I
submitted it.
Change-Id: I92aca64a9f3eee5b7ede6e9fa37d3b12d3f5d1f7
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3729
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
I intend to use this for updates on TVL projects, which will end up on
the homepage, which is outside of //users.
Change-Id: I03542d1bcef3d9fc4599294655caab5ed22ba5d9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3728
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
The default gcc version for pkgsCross.avr.buildPackages is 10.x, which
seems to be able to build the layout derivation just fine.
Change-Id: Ib7790419f38121ea2b1a09c790ef3a04afc0f9f8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3712
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
nixpkgs-crate-holes can build a markdown report detailing all vulnerable
crates pinned in cargoDeps vendors in nixpkgs according to RustSec's
advisory db. This report is intended to be pasted into a GitHub issue.
The report is produced by a derivation and can be obtained like this:
nix-build -A users.sterni.nixpkgs-crate-holes.full \
--argstr nixpkgsPath /path/to/nixpkgs
Example output: https://gist.github.com/sternenseemann/27509eece93d6eff35cd4b8ce75423b5
Additionally, you can obtain a more verbose report for a single
attribute of nixpkgs, in HTML format since we just reuse the command
line output of cargo-audit and convert it to HTML using ansi2html:
nix-build -A users.sterni.nixpkgs-crate-holes.single \
--argstr nixpkgsPath /path/to/nixpkgs --argstr attr ripgrep
Change-Id: Ic1c029ab67770fc41ba521b2acb798628357f9b2
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3715
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
This makes it much easier to update the db manually and also lays the
foundation for future automation bumping the advisory db.
Change-Id: I1244020c8bb1af43bf4e207c55f6420eb3f57bcf
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3713
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Profpatsch <mail@profpatsch.de>
... the amount of times I've not had this and nix-shell'd it is ridiculous.
Change-Id: I8ac3a7a2915e68d235f8349373b2575e6ebe1cb5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3710
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
cleanSource needs to import the path into store which is quite slow at
this point. Since we are filtering the path later anyways, using the
original path is probably perfectly fine and speeds up builds (which is
nice when iterating on something).
Change-Id: I0628854d754b5903eb4ae93a3c3e2539b2c1c7e9
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3705
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Passed strings will be treated as a relative path below the given root,
which is quite convenient when using depot.path by eliminating a lot of
repetition.
Change-Id: I3da6058094484f4a6ffbb84f89ad4472b502a00c
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3704
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
The point where this broke is likely when llvmPackages_11.stdenv started
respecting stdenv.hostPlatform.linker and thus using GNU binutils'
ld.bfd for linking. That linker can't deal with clang's C++ ABI.
To fix this we introduce a modified version of llvmPackages_11.stdenv
which uses llvmPackages_11.bintools for linking purposes (I also aim to
upstream this in some form, but am not sure about the details atm, so
we'll just do this in the tvl overlay for now). This is the precondition
for getting our C++ packages in //third_party to work
again. Additionally the following fixes were necessary:
* abseil-cpp needed to be updated (by overriding the version from
nixpkgs for now, since I can't update the subtree on my own) to
fulfill grpc's requirements (grpc 1.41.0 needs abseil-cpp LTS
20210324).
* gtest needs a patch from nixpkgs which fixes the path to its include
directory for CMake.
* We need to build re2 with clang as well, otherwise linking will fail.
Fixes b/132.
Change-Id: I7b64579fe96451547babe070fd35db398581e49d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3701
Tested-by: BuildkiteCI
Reviewed-by: lukegb <lukegb@tvl.fyi>
Reviewed-by: tazjin <mail@tazj.in>
Replaces all uses of relative static paths in TVL pages with the
static.tvl.fyi domain. Where possible, the drv hash is directly
embedded in the content.
Change-Id: Ia882dd37ceae9d047cd81cf1eb37a856b339643a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3682
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
The previous hash had a weird salt length and a trailing newline.
This fixes it.
Change-Id: I1f03238181d0caad38e1f1dbc477356bc20fc32d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3689
Reviewed-by: tazjin <mail@tazj.in>
Tested-by: BuildkiteCI
This ensures in a simple example that __readTree and __readTreeChildren
are populated correctly.
Change-Id: I69a46b2ddde0d1f9bf0dff1c4780f033ac8fc27a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3655
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
In order to make readTree import symlinked directories I've been looking
into how to detect if a symlink points to a directory (since this would
allow us to use symlinks for //nix/sparseTree). I've found a hack for
this:
symlinkPointsToDir = path: isSymlink path &&
builtins.pathExists (toString path + "/.")
Unfortunately it doesn't seem to be possible to distinguish whether the
symlink target does not exist or is a regular file.
Since it's possible, I thought might as well add this to
`pathType`. To make returning the extra information workable, I've
elected to use the attribute set layout used by `//nix/tag`. This
doesn't require us to depend anything (as opposed to yants), but gives
us pattern matching (via `nix.tag.match`) and also quite idiomatic
checking of pathTypes:
pathType ./foo ? file
(pathType ./foo).symlink or null == "symlink-directory"
Nonexistent paths are encoded like this:
pathType ./foo ? missing
Of course we can't use this in readTree (since it must be zero
dependency), but we can easily inline this hack at some point.
Change-Id: I15b64a1ea69953c95dc3239ef5860623652b3089
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3535
Tested-by: BuildkiteCI
Reviewed-by: Profpatsch <mail@profpatsch.de>
Reviewed-by: tazjin <mail@tazj.in>
The setup is explained in the comment, but TL;DR: Use the derivation
hash of static files to create permanent URLs.
Relates to b/151.
Change-Id: Ib1ca3a1a00c90a47f4bf39c29a8b4bbf5b215e7d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3664
Tested-by: BuildkiteCI
Reviewed-by: grfn <grfn@gws.fyi>
This hostname can be used for hosting static assets with aggressive
caching for everything, or potentially CDNing stuff if we ever have
large things here.
Change-Id: I10afdad5eb08125d8d09108e9e099f5573362fe5
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3663
Reviewed-by: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
This can be used for easy cachebusting of static assets, so that we
can serve them all with a really long cache-time easily.
Change-Id: I7c9f6beddec58e1caf02cda33bc587590217a939
Reviewed-on: https://cl.tvl.fyi/c/depot/+/3660
Tested-by: BuildkiteCI
Reviewed-by: sterni <sternenseemann@systemli.org>
