| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
passes the basic smoke test, nothing else done (doing this to distract
myself & since people expressed interest in maybe trying to run an
instance again).
|
|
|
|
|
| |
also element has now bundled in the matrix-react-sdk, so some paths
inside it have changed.
|
| |
|
|
|
|
|
| |
this had been removed last week since nixpkgs had broken the rebar3
build on erlang-nox, but it seems to work again, so yay for that!
|
| |
|
| |
|
|
|
|
|
|
|
| |
having tried multiple times, it's not actually very possible or
reasonable to attempt to keep lean's version in sync with whatever
mathlib requires at any given time, and probably better to have it just
be managed by elan, no matter how annoying that may be.
|
|
|
|
|
|
|
|
|
|
|
|
| |
this does a lot of things, most of which are maintenance:
- sources update
- adjust newly-renamed options
- swap some packages that were removed / renamed
- update nomsring to newer default ghc
- remove the deprecated lib.mdDoc from modules/*.nix
- disable the nixpkgs mollysocket module so my own keeps evaluating
- bundle the package definition of hikari & wlroots 0.15, which nixpkgs
has removed as unmaintained (in fairness, they are unmaintained)
|
|
|
|
|
| |
turns out these overrides are more convoluted than I expected, but I
think (?) this should now actually catch all of them.
|
|
|
|
|
|
|
|
| |
since nixos-rebuild does not support applying a built config (i.e. one
on which eval-config has already been called) without flakes.
I might or might not extend this into a more proper reimplementation of
nixos-rebuild.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this is, in the widest possible sense, a revert of
e88fed18f499a3e8ac98c772bbb62f00d1f8d1d7, which was now a little over
two years ago.
Of course, lots of things have changed since then:
- this uses npins instead of niv, which is both simpler and still
maintained
- i haven't brought back the old deploy lib; I still use
deploy-rs (with some modifications) to deploy things
- if you actually use my stuff downstream, you can now use packages/ &
tests/ & modules/ as entry points directly, while still having some
control over inputs
- (since i also don't believe any downstream users actually exist, i've
not bothered to have a shim flake.nix so your stuff probably just
broke. well, it was an experimental feature, anyways)
- in general there's a lot more of the old-fashioned structure back
again, with default.nix files in subdirectories that form a
structure, not like how almost everything was just imported in the
one big flake.nix file
For people who are interested in also having a non-flake config similar
to this one, it's probably best to take a look at inputs.nix (and also
at npins, of course)
|
|
|
|
|
|
|
| |
this is the rust tool used by the french ministry for
transport (deployed at https://transport.data.gouv.fr/validation),
patched to not include the server mode it usually has (i don't want to
constantly compile another copy of actix-web)
|
|
|
|
|
| |
thanks to networkException for demonstrating how to do this; I'd not
have had the patience to figure out which files to replace otherwise.
|
|
|
|
|
|
| |
This reverts commit a86a04f9e26854ec967c46a6ad3f015364fb91a6. It has
since been merged into nixpkgs master, and i'm unsure if i will continue
using it.
|
| |
|
|
|
|
|
|
|
| |
without this, there's lots of extra space since the in-javascript layout
script thinks boxes take up more space than they actually do
(i think there was this nice idea, once, about separating the UI from
the rest of the application? ah well)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
since schildichat-web has essentially been unmaintained for a while now,
i guess i don't really have any choice here.
I've tried to at least hack a little css into my element so it won't
bother me too much (mostly making UI elements smaller & changing some
colours). However, it turns out they do UI calculations in javascript
which just make hard assumptions over values set in the css, and so far
I've not succeeded in fixing these.
Das ist doch wirklich alles Unsinn in diesem Ökosystem …
|
|
|
|
|
|
|
| |
not sure if this is a good idea or not, but i always liked how the
IRC #voc-wok channel of the c3voc works, and I don't run my own IRC (nor
do i want to have my monitoring on infra that is not my own), so I built
a similar thing with matrix.
|
|
|
|
| |
https://github.com/NixOS/nixpkgs/pull/278981
|
|
|
|
|
| |
the tool is still a bit rough, but it should work well enough for actual
use (even if i have to restart xochitl afterwards)
|
|
|
|
|
|
|
|
| |
- pkgs/ should now also contain all package overrides
- pkgs/patches/ now contains all patches
- nix flake info succeeds again
- still not sure what to do about scripts
- services which are not used should not be kept around this long
|
|
|
|
| |
with thanks to networkException, who wrote the initial nix package.
|
|
|
|
|
|
|
| |
this is still missing:
- a nice way to do settings
- lots of testing (run the manage.py test script in a nixos test?)
- an actual way to deploy this in a halfway reasonable way
|
|
|
|
| |
(just messing around for now)
|
| |
|
| |
|
| |
|
|
|
|
| |
not tested, but like, why not? Might be fun playing around with it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
this packages the heartwood cli tools, the radicle web interface, and
runs a small example deployment on chaski.
TODO: decide if i want to keep this thing, then add declarative config
of the web interface, `rad auth`, and the radicle node to a NixOS
module; the current state is kinda suboptimal to deploy.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
apparently the default homeserver this uses is not configurable???
… might hack around later
|
| |
|
| |
|
| |
|
|
|
|
| |
constantly rebuilding the world just got too annoying
|
|
|
|
|
| |
might have to revert this if it causes problems, or if rebuilding all
the things annoys me too much.
|
| |
|
| |
|
|
|
|
|
| |
setting elixir = elixir_1_14 may get me trouble later, we'll see
(version bounds on bahnhof.name's search engine are weird)
|
|
|
|
|
|
|
|
| |
in gleam, because why not?
(tbf i will probably eventually rewrite this in a more sensible
language; I haven't even found any reason to use any of the OTP features
for this 🙈)
|
| |
|