| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
| |
with thanks to networkException, who wrote the initial nix package.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
please no one like, actually use this. unless you volunteer to at least
add a script to run database migrations, since currently these need to
be run by hand …
|
| |
|
|
| |
in case i ever think i need such a thing, i guess
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This pleroma config should be able to set itself up without any
manual intervention (modulo the secrets file, which is almost empty).
Annoyingly, the pleroma nixpkg is built from the pipeline artifacts
of the pleroma gitlab and does not have support for pleroma's ssh/bbs
mode.
|
|
|
This deploy logic is primarily based on hxchn's deploy lib [1], with some
slight modifications to make it work with my setup. Everything seems to work
fine for now.
However, I am unsure about the usage of niv — the config doesn't seem to gain
much from it, apart from (some) additional complexity.
[1] https://gitlab.com/hexchen/nixfiles
|
