It's actually quite common that a token provider might fail, for
example when fetching a token from instance metadata.
Change-Id: Ie0126fb92c6c613ad36b5583fd68505fdd97f2c1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8764
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
These are useful for downstream users of the library, who might not
need all the rest of the tonic stuff.
Change-Id: Iab4d941696ae3c7a33b25815b72f92598aa82b80
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8763
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
I don't actually use this, and it might be responsible for some EXWM
bugs in the latest version.
Change-Id: I8817e0cdd9d1b68ed6a9bdd072616f63f9f20d21
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8758
Autosubmit: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
reddit is dying now, but the response there was actually quite
interesting, so I'm keeping an archive link to it around.
Change-Id: I419276428ce141fc526124d9746e3ab13df4bbc8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8756
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
There's very little reason to instantiate a GRPCPathInfoService in a
context where we are not already in a tokio context.
Change-Id: Ib81d649387717cb98de8a8039f92472f727b10c1
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8755
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
The only place where we did use new was also already where we've been in
a tokio context, so just using from_client is easier.
Change-Id: I39dbc18f6aaa3abc342409be623395647f968530
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8754
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
There's very little reason to instantiate a GRPCBlobService in a context
where we are not already in a tokio context.
Change-Id: Ic6e18809a9f2a76f1c098ed330118d8dcfba5137
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8753
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
This removes the use of generics, like previously done with Blob and
Directory services.
Change-Id: I7cc8bd1439b026c88e80c11e38aafc63c74e5e84
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8751
Tested-by: BuildkiteCI
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: tazjin <tazjin@tvl.su>
We never returned Err here anyways, and we can still return an error
during the first (or subsequent) write(s).
Change-Id: I4b4cd3d35f6ea008e9ffe2f7b71bfc9187309e2f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8750
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
From 64 bytes to 100 KBytes.
We need to provide a custom wrapper with a different Default instance.
Change-Id: Id7c6c437b8183b355a9e388f98cef1622b363f64
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8748
Tested-by: BuildkiteCI
Reviewed-by: flokli <flokli@flokli.de>
This allows us to blob services without closing them before putting them
in a box.
We currently need to use Arc<_>, not Rc<_>, because the GRPC wrappers
require Sync.
Change-Id: I679c5f06b62304f5b0456cfefe25a0a881de7c84
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8738
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Autosubmit: flokli <flokli@flokli.de>
Once we support configuring services at runtime, we don't know what
DirectoryService we're using at compile time.
This also means, we can't explicitly use the is_closed method from
GRPCPutter, without making it part of the DirectoryPutter itself.
Change-Id: Icd2a1ec4fc5649a6cd15c9cc7db4c2b473630431
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8727
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Putting this in the PathInfoService trait makes much more sense, we can
have direct control over where/how to cache the results in the
implementation.
This now requires each PathInfoService to hold pointers to BlobService
and DirectoryService.
Change-Id: I4faae780d43eae4beeb57bd5e190e6d1a5d3314e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8724
Tested-by: BuildkiteCI
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: tazjin <tazjin@tvl.su>
There's only one way to calculate NAR files, by walking through them.
Things like caching such replies should be done closer to where we use
these, composing NARCalculationService doesn't actually give us much.
Instead, expose two functions, `nar::calculate_size_and_sha256` and
`nar::writer_nar`, the latter writing NAR to a writer, the former using
write_nar to only keeping the NAR size and digest.
Change-Id: Ie5d2cfea35470fdbb5cbf9da1136b0cdf0250266
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8723
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Autosubmit: flokli <flokli@flokli.de>
To construct various stores at runtime, we need to eliminate associated
types from the BlobService trait, and return Box<dyn …> instead of
specific types.
This also means we can't consume self in the close() method, so
everything we write to is put in an Option<>, and during the first close
we take from there.
Change-Id: Ia523b6ab2f2a5276f51cb5d17e81a5925bce69b6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8647
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
Unfortunately, nixpkgs has at least one case[1] where the out environment
variable is shadowed -- though it doesn't cause a problem, since it's
shadowed with the correct value, odd as this may be!
[1]: c7c2984716/pkgs/development/python-modules/pybind11/default.nix (L19)
Change-Id: Ibf6790d2484dc9cce8e424feeb5886664d498dc3
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8696
Autosubmit: tazjin <tazjin@tvl.su>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
`tvix-store mount PATH` will mount the tvix-store to the given path.
Change-Id: Icb82a6b3cb8a22eec856c375a28ae5580403833f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8665
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Autosubmit: flokli <flokli@flokli.de>
This allows using a StorePath as a key in a hashmap.
Change-Id: Id3eed623da4e1fc44a970a3982c7caa21d2495c8
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8666
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
This brings in fuse (via the `fuser` crate), and adds pkg-config and
libfuse to the dev shell, so `cargo build` can link against it.
Change-Id: I0d11607490e27d946bdf92b0b9e45f9ab644ba74
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8664
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
Gotta use a shared crate for this ..
Change-Id: I57669bdcace9676ff1311f3171c015702c934f56
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8734
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
This UUID stays the same even if a user submits the form multiple
times (unless they edit it manually in local storage, of course).
Change-Id: I4190fbfeb1027ce8a8d87bc283099539e8722b39
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8733
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
This testcase tests a missing blob fails the rendering, the comment has
been copied from elsewhere.
Change-Id: I48fa3fa454e12506590fa14a3591d156bafa8b5e
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8722
Reviewed-by: tazjin <tazjin@tvl.su>
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
The CLs did bitrot a bit, they're based on an older version of the
protocol, and it's unclear if they'll be a separate Go Binary, or just
another HTTP handler inside tvix-store itself, considering we now have
way more NAR juggling code than before.
Change-Id: I3632035cda8d75a8ff23b3132312f0f086d9e02f
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8732
Autosubmit: flokli <flokli@flokli.de>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
This has moved to a `daemon` subcommand.
Change-Id: Iae9778d8a59e6bf84555119fabfd62db3917bb62
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8731
Tested-by: BuildkiteCI
Autosubmit: flokli <flokli@flokli.de>
Reviewed-by: tazjin <tazjin@tvl.su>
Note that there doesn't seem to be a TF resource type for the IAM
binding between the bucket and the service account itself (other than
applying to all buckets in the folder, which I don't want).
For this reason I've added the `storage.uploader` IAM binding to the
`rih-backend` service account *on the bucket* manually.
Change-Id: I9fb06c7857e61dc642d9ea0d89159a0e343dc984
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8728
Reviewed-by: tazjin <tazjin@tvl.su>
Tested-by: BuildkiteCI
For the case of vertical columns of workareas, top and bottom struts
should only apply to workareas containing the respective edge of the
strut offset.
To simplify, imagine three monitors arranged vertically and one
workarea per display:
+-------+
| 1 | 2000x1000 px
+-------+
| 2 | 2000x1000 px
+-------+
| 3 | 2000x1000 px
+-------+
In sexp form: ((0 0 2000 1000) (0 1000 2000 1000) (0 2000 2000 1000))
where each element represents a workarea as x, y, width, height
And example struts of the form (offset-type offset (x-start x-end))
a.) (top 42 (0 2000))
b.) (top 1042 (0 2000))
c.) (top 2042 (0 2000))
d.) (bottom 42 (0 2000))
e.) (bottom 1042 (0 2000))
f.) (bottom 2042 (0 2000))
Workareas adjusted for struts before this change:
a.) ((0 42 2000 958) (0 1000 2000 1000) (0 2000 2000 1000))
b.) ((0 1042 2000 -42) (0 1042 2000 958) (0 2000 2000 1000))
c.) ((0 2042 2000 -1042) (0 2042 2000 -42) (0 2042 2000 958))
d.) ((0 0 2000 1000) (0 1000 2000 1000) (0 2000 2000 902))
e.) ((0 0 2000 1000) (0 1000 2000 902) (0 2000 2000 -98))
f.) ((0 0 2000 902) (0 1000 2000 -98) (0 2000 2000 -1098))
Note that a. and d. are sensible, while b., c., e., and f. are quite
user unfriendly.
After this change, the same adjusted workareas are:
a.) no change
b.) ((0 0 2000 1000) (0 1042 2000 958) (0 2000 2000 1000))
c.) ((0 0 2000 1000) (0 1000 2000 1000) (0 2042 2000 958))
d.) no change
e.) ((0 0 2000 1000) (0 1000 2000 902) (0 2000 2000 1000))
f.) ((0 0 2000 902) (0 1000 2000 1000) (0 2000 2000 1000))
The intent is to allow dock type windows such as typical status bars
to occupy space in a workarea on any of a set of vertically arranged
displays without occluding the other workareas due to the limitations
of the X spec regarding strut offsets.
Note that this behaviour conflicts with EWMH 1.3:
> Struts MUST be specified in root window coordinates, that is,
they are *not* relative to the edges of any view port or Xinerama
monitor.
but is accepted by multiple WMs. See:
- https://blog.martin-graesslin.com/blog/2016/08/panels-on-shared-screen-edges/
- https://mail.gnome.org/archives/wm-spec-list/2009-November/msg00005.html
- https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/22
* exwm-workspace.el (exwm-workspace--update-workareas): Assume
vertical struts apply from the monitor boundary when they cross
them.
Copyright-paperwork-exempt: yes
