| Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
the nix-env logic was still broken. It seems to have extremely weird
failure modes under which it does not report errors when doing
nix-env --set, or else the switch-to-configuration.pl script does not
properly install the boot loader entry when it was installed via --set
instead of --install.
I'm not entirely clear on why yet, will need some investigating.
|
|
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)
|
|
unfortunately, these tests seem to be broken at the moment? Or at least
I cannot see where my packaging differs from the provided cpanfile.snapshot.
|
|
quite a bunch of these packages now need manually adjusted build
inputs (most often just adding TestSuite2) to make the tests not fail.
|
|
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.
|
|
Not sure yet how much (if anything) I'll actually do with this, but it
seemed like a fun idea to try and it's been way to long since I wrote
anything in scheme.
Entirely untested, as I don't actually have a prometheus running atm
(apart from the one specifically for tracktrain on chaski).
|
|
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.
|
|
since that website doesn't contain anything anyways, but people started
linking to it.
|
|
|
|
otherwise it just fails to start with an error
|
|
this allows setting options via an environment file that is passed to
the systemd units, in addition to the ones set during build time of the
package.
For now this is tailored to SECRET_KEY, but it may be useful for other
settings as well (e.g. EMAIL_HOST_PASSWORD), and I'm not sure if it
takes priority over the build-time settings ...
|
|
this should be mostly usable for actual deployments. Only thing that's
really still annoying is having to set the SECRET_KEY via Nix, since
not having set it makes the package fail to build. But it doesn't
actually end up in the derivation, so changing it afterwards should be
fine; I've just not tested that yet.
|
|
|
|
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
|
|
|
|
|
|
|
