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
* exwm-workspace.el (exwm-workspace--remove-frame-as-workspace):
Add optional argument quit.
* exwm-background.el (exwm-background--exit):
* exwm-input.el (exwm-input--exit):
* exwm-manage.el (exwm-manage--unmanage-window):
* exwm-systemtray.el (exwm-systemtray--exit):
* exwm-workspace.el (exwm-workspace--exit-minibuffer-frame)
(exwm-workspace--exit):
* exwm-xim.el (exwm-xim--exit): Observe connection status when
deinitializing in order to support deinitializing when the
connection breaks.
`exwm-input--exit` could be called (via `exwm-exit`) from `exwm-init`
in case of error when initialising EXWM. It could happen that the bit
that failed when exwm-init is executed was the call to `xcb:connect`,
hence `exwm--connection` would be nil when errors are handled (and
`exwm-exit` is called).
Without this patch, in the case above, the user will see a crash as
there's no method allowing a nil XCB connection object:
Debugger entered--Lisp error:
(cl-no-applicable-method xcb:-+request nil #<xcb:SetInputFocus ...
even worse, not even giving the chance to the `warn` call in
`exwm-init`'s error handler to actually inform the user about the
actual problem ("[XELB] Connection timeout", for instance).
* exwm-input.el (exwm-input--exit): Check `exwm--connection' is
set before trying to send requests.
When comparing to C++ Nix, we notice that the thunking of default
expressions in function formals corresponds to their normal thunking,
e.g. literals are not thunked. This means that we can just invoke
compile() without much of a care and trust that it will sort it out
correctly.
If function formals blow up as a result of this, it likely indicates
that the expression is treated incorrectly by compile(), not
compile_param_pattern().
Change-Id: I64acbff2f251423eb72ce43e56a0603379305e1d
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8704
Autosubmit: sterni <sternenseemann@systemli.org>
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
C++ Nix forces and typechecks the passed argument even if it is not
necessary in order to compute the return value of the function. I
discovered this when I thought our formals miscompilation might be that
we are too strict, but doesn't look like it in this case.
Change-Id: Ifb3c92592293052c489d1e3ae8c7c54e4b6b4dc6
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8701
Tested-by: BuildkiteCI
Autosubmit: sterni <sternenseemann@systemli.org>
Reviewed-by: tazjin <tazjin@tvl.su>
A recent upgrade is requiring this now for some reason.
Change-Id: I5908c12d104044897b4969dbd1299a3071d507bd
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8716
Tested-by: BuildkiteCI
Autosubmit: grfn <grfn@gws.fyi>
Reviewed-by: grfn <grfn@gws.fyi>
The completion detection is very naive for now, but baby steps etc.
Change-Id: Iec6eae77fca13f3fc0ee1225268eef04277b504a
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8702
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
This turned out a lot nicer than I expected it to be.
Change-Id: I427670644eba789ea2037423fa9af8e632b19b34
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8695
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
This makes more sense to me.
Change-Id: I013bf9457f20a31a9762768607f4094358e1b7cb
Reviewed-on: https://cl.tvl.fyi/c/depot/+/8693
Tested-by: BuildkiteCI
Reviewed-by: tazjin <tazjin@tvl.su>
This is almost one year of changes to EXWM. Note that it undoes our
port of https://github.com/ch11ng/exwm/pull/737
That PR hasn't seen any movement in three years, so it might not be
that relevant anymore. Other stuff has been mainlined in the meantime.
Change-Id: I0845ff8a28a5bb1553855f6d6f0ceeaedcf0809e
