this bundles the current package recipe of forgejo in nixpkgs-unstable.
Implies updating forgejo, since nixpkgs-stable is still on 1.20.6 (v6 in
the new version scheme).
This'll mean we have to manually update it same as with mattermost, and
can potentially also help with upstream changes. If we get tired of
that, we can always decide to just use the nixpkgs-unstable version
directly.
Since Lix is now in nixpkgs-unstable-small, I think it's a good time to
use it. This does mean that we now pull in our nix implementation from
an unstable channel, but overall I'm more confident in the Lix team's
ability to not break things than I am in the Nix team's ability to
backport (& then actually release) security updates.
(once Lix is on a stable channel, we can switch back to using it from there)
this copies the current mattermost package definition from upstream
nixpkgs into our repo as-is (that definition itself being a modified
version of our definition that I upstreamed recently).
Since apparently no one else is maintaining the nixpkgs package and I am
apparently maintaining a mattermost package mostly on my own anyways,
this should make upstreaming future changes easier.
This jumps Mattermost ESR Versions (see [1] for their release cycle). The
new version makes use of Go's workspace feature, which unfortunately the
buildGoModule function does not (yet?) support [2], and unfortunately this
breaks the previous build process for mattermost.
Further, the new release also makes use of private modules only included
in the (non-free) enterprise version of mattermost which makes it impossible
to build in the usual way even outside of nixpkgs's build abstractions [3].
Both issues can be solved by using Go 1.22, which has added support for
vendoring when using workspaces, and instructing it to ignore errors with
the -e flag. This requires overriding the go-modules derivation's buildPhase.
Finally, this now also build the commands/mmctl subpackage, which contains
a cli utility to administrate mattermost. This currently has its own nixpkgs
package for no reason i can see at all (it also has a version mismatch
between nixpkgs's mattermost and nixpkgs's mmctl).
[1] https://docs.mattermost.com/upgrade/extended-support-release.html
[2] https://github.com/NixOS/nixpkgs/issues/203039
[3] https://github.com/mattermost/mattermost/issues/26221
we decided to:
- get rid of unused packages
- simpify the directory layout since we only have one host anyways
- move our docs (such as they are) in-tree
move some options (the nopersist & container profiles + allowUnfree
packages) into the evalConfig used for containers, so we don't have to
repeat ourselves as much.
also removed some no-longer-needed specialArgs.
also made thelounge work with nopersist, which for some reason it didn't
use before.
This reverts commit 90f4971e88d22da6b2a213bbeb1790f456024b36, and resets
the uffd version to the one we are already using, in hopes of making the
update slightly less painfull (haha).
this replaces niv with nix flakes, attempting to preserve the old
structure as much as possible. Notable caveats:
- I'm not sure if flake inputs expose version information anywhere, so
the version in pkgs/mattermost/default.nix is now hardcoded.
Confusingly, this appears to trigger a rebuild. Maybe I've missed something.
- a lot of the old-style host.nix & deploy.nix machinery in nix-hexchen
does not work with flakes, and their newer replacements are not exposed
by upstream; I've put basic imitations of the relevant parts in this repo
- (in particular, directories in hosts/ won't become deployable configs
automatically)
- parts of the code are now probably more complicated than they'd have to be
- old variables names were preserved; confusingly, this means the flake
inputs are still called "sources"
Intended for KontraIAA; requirements were that it should be a simple and
non-confusing as possible.
I tried both KiwiIRC and thelounge, and found both horrible to
package (a fact not helped by the somewhat opaque structure of
nixpkgs.nodePackages, which does contain a version of thelounge but
will apparently ignore overrides of the src attribute).
Instead, this now contains a very hacky version of thelounge, which
merely takes the already-built version from nixpkgs and glues some extra
css to it which hides potentially confusing fields.
Things hidden on the "connect" screen:
- the "name" field (since thelounge offers "nick" "name" and "realname"
by default, which seems too much for something embedded on a website)
- the "I have a password" checkbox
Things hidden on the general view:
- the button to open the side panel (the panel itself is not hidden,
and will appear by itself on wider layouts), so that users will only
see that one channel
- the "channel options" menu (which includes a "leave channel" option
which would effectively break the webchat)
Things not addressed:
- thelounge has autocompletion for /join /leave, etc. Do we want to
disable that as well?
- It would probably useful to suppress all the "x joined the channel"
messages. Thelounge supports this, but apparently doesn't support
setting it as default?
Misc:
- for now, users will be connected to #thelounge on libera.chat, which
appears to be okay with being used as an experimental channel
- I allowed prefetching link previews, but only on the server's side
(i.e. users' browsers won't fetch content from arbitrary sites)
- not yet tested on hainich, but should work (tested in a NixOS
container)
- currently assumes a "webchat.voc.hacc.space" domain (I think we had a
voc domain? but I forgot where it is …)
nixos and its concepts/service management/update mechanism don't play nice with minecraft
In general some things I wanted to do (e.g. a map) are to spikiely resource intensive to run on a server meant to provide other services consistently
A replacement will be provided soon™
this is a workaround to be able to use java 11 with the
minecraft-server module
minecraft calls for jre_headless, which is still java 8
newer java version don't ship jre, which now have to be custom built or
the jdk used
lots of fancy new stuff, but most importantly: we no longer import all
of my user config, just the very base.
none of that fancy stuff is active right now, this should mostly be a
no-op unless we do the same restructure that i have just done in my
nixfiles here as well.
