hacc/haccfiles
8
0
Fork 1
Code Issues 1 Pull requests Projects Releases Wiki Activity
haccfiles/flake.lock

267 lines
7 KiB
Text
Raw Normal View History

shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
{
"nodes": {
"blobs": {
"flake": false,
"locked": {
"lastModified": 1604995301,
"narHash": "sha256-wcLzgLec6SGJA8fx1OEN1yV/Py5b+U5iyYpksUY/yLw=",
"owner": "simple-nixos-mailserver",
"repo": "blobs",
"rev": "2cccdf1ca48316f2cfd1c9a0017e8de5a7156265",
"type": "gitlab"
},
"original": {
"owner": "simple-nixos-mailserver",
"repo": "blobs",
"type": "gitlab"
}
},
"deploy-rs": {
"inputs": {
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"flake-compat": "flake-compat",
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"nixpkgs": [
"nixpkgs"
],
"utils": "utils"
},
flake: add deploy-rs
2022-11-13 22:04:55 +00:00
"locked": {
update inputs
2024-04-08 23:02:51 +00:00
"lastModified": 1711973905,
"narHash": "sha256-UFKME/N1pbUtn+2Aqnk+agUt8CekbpuqwzljivfIme8=",
flake: add deploy-rs
2022-11-13 22:04:55 +00:00
"owner": "serokell",
"repo": "deploy-rs",
update inputs
2024-04-08 23:02:51 +00:00
"rev": "88b3059b020da69cbe16526b8d639bd5e0b51c8b",
flake: add deploy-rs
2022-11-13 22:04:55 +00:00
"type": "github"
},
"original": {
"owner": "serokell",
"repo": "deploy-rs",
"type": "github"
}
},
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"flake-compat": {
initial work towards nixos 23.11 Note: this updates all postgres instances, since postgresql_11 no longer exists.
2023-11-30 16:43:48 +00:00
"flake": false,
"locked": {
"lastModified": 1696426674,
"narHash": "sha256-kvjfFW7WAETZlt09AgDn1MrtKzP7t90Vf7vypd3OL1U=",
"owner": "edolstra",
"repo": "flake-compat",
"rev": "0f9255e01c2351cc7d116c072cb317785dd33b33",
"type": "github"
},
"original": {
"owner": "edolstra",
"repo": "flake-compat",
"type": "github"
}
},
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"nixos-mailserver": {
"inputs": {
"blobs": "blobs",
initial work for 23.05 in theory this might be ready to deploy. Potential hazards & things to know when actually doing so: 1. the mysql version used by mattermost was updated (the old uses an openssl which is marked insecure). Might have to migrate a database 2. lots of settings now use RFC 42-style settings, which might contain new typos 3. this updates uffd (& changes the patches we apply). Since version dependencies of uffd are basically "whatever debian has" we have never bothered to match them, but afaik have also never updated uffd since the initial deploy some years ago. No guarantee it still works. 4. tracktrain depends on haskellPackages.conferer-warp, which is currently marked broken. There is no reason for this (it builds fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1. cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a merge of haskell-updates into 23.05
2023-06-06 00:04:11 +00:00
"flake-compat": [
"deploy-rs",
"flake-compat"
],
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"nixpkgs": "nixpkgs",
initial work for 23.05 in theory this might be ready to deploy. Potential hazards & things to know when actually doing so: 1. the mysql version used by mattermost was updated (the old uses an openssl which is marked insecure). Might have to migrate a database 2. lots of settings now use RFC 42-style settings, which might contain new typos 3. this updates uffd (& changes the patches we apply). Since version dependencies of uffd are basically "whatever debian has" we have never bothered to match them, but afaik have also never updated uffd since the initial deploy some years ago. No guarantee it still works. 4. tracktrain depends on haskellPackages.conferer-warp, which is currently marked broken. There is no reason for this (it builds fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1. cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a merge of haskell-updates into 23.05
2023-06-06 00:04:11 +00:00
"nixpkgs-23_05": [
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"nixpkgs"
],
update inputs; simple-nixos-mailserver now has a 23.11 branch
2024-01-08 21:21:05 +00:00
"nixpkgs-23_11": "nixpkgs-23_11",
initial work for 23.05 in theory this might be ready to deploy. Potential hazards & things to know when actually doing so: 1. the mysql version used by mattermost was updated (the old uses an openssl which is marked insecure). Might have to migrate a database 2. lots of settings now use RFC 42-style settings, which might contain new typos 3. this updates uffd (& changes the patches we apply). Since version dependencies of uffd are basically "whatever debian has" we have never bothered to match them, but afaik have also never updated uffd since the initial deploy some years ago. No guarantee it still works. 4. tracktrain depends on haskellPackages.conferer-warp, which is currently marked broken. There is no reason for this (it builds fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1. cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a merge of haskell-updates into 23.05
2023-06-06 00:04:11 +00:00
"utils": [
"deploy-rs",
"utils"
]
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
},
"locked": {
update inputs
2024-01-30 13:46:02 +00:00
"lastModified": 1706219574,
"narHash": "sha256-qO+8UErk+bXCq2ybHU4GzXG4Ejk4Tk0rnnTPNyypW4g=",
do unspeakable things to flake.lock
2022-11-15 14:33:06 +00:00
"owner": "simple-nixos-mailserver",
"repo": "nixos-mailserver",
update inputs
2024-01-30 13:46:02 +00:00
"rev": "e47f3719f1db3e0961a4358d4cb234a0acaa7baf",
do unspeakable things to flake.lock
2022-11-15 14:33:06 +00:00
"type": "gitlab"
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
},
"original": {
do unspeakable things to flake.lock
2022-11-15 14:33:06 +00:00
"owner": "simple-nixos-mailserver",
update inputs; simple-nixos-mailserver now has a 23.11 branch
2024-01-08 21:21:05 +00:00
"ref": "nixos-23.11",
do unspeakable things to flake.lock
2022-11-15 14:33:06 +00:00
"repo": "nixos-mailserver",
"type": "gitlab"
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
}
},
"nixpkgs": {
"locked": {
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"lastModified": 1705856552,
"narHash": "sha256-JXfnuEf5Yd6bhMs/uvM67/joxYKoysyE3M2k6T3eWbg=",
initial work for 23.05 in theory this might be ready to deploy. Potential hazards & things to know when actually doing so: 1. the mysql version used by mattermost was updated (the old uses an openssl which is marked insecure). Might have to migrate a database 2. lots of settings now use RFC 42-style settings, which might contain new typos 3. this updates uffd (& changes the patches we apply). Since version dependencies of uffd are basically "whatever debian has" we have never bothered to match them, but afaik have also never updated uffd since the initial deploy some years ago. No guarantee it still works. 4. tracktrain depends on haskellPackages.conferer-warp, which is currently marked broken. There is no reason for this (it builds fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1. cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a merge of haskell-updates into 23.05
2023-06-06 00:04:11 +00:00
"owner": "NixOS",
"repo": "nixpkgs",
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"rev": "612f97239e2cc474c13c9dafa0df378058c5ad8d",
initial work for 23.05 in theory this might be ready to deploy. Potential hazards & things to know when actually doing so: 1. the mysql version used by mattermost was updated (the old uses an openssl which is marked insecure). Might have to migrate a database 2. lots of settings now use RFC 42-style settings, which might contain new typos 3. this updates uffd (& changes the patches we apply). Since version dependencies of uffd are basically "whatever debian has" we have never bothered to match them, but afaik have also never updated uffd since the initial deploy some years ago. No guarantee it still works. 4. tracktrain depends on haskellPackages.conferer-warp, which is currently marked broken. There is no reason for this (it builds fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1. cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a merge of haskell-updates into 23.05
2023-06-06 00:04:11 +00:00
"type": "github"
},
"original": {
update inputs
2023-09-25 15:14:45 +00:00
"id": "nixpkgs",
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"ref": "nixos-unstable",
update inputs
2023-09-25 15:14:45 +00:00
"type": "indirect"
initial work for 23.05 in theory this might be ready to deploy. Potential hazards & things to know when actually doing so: 1. the mysql version used by mattermost was updated (the old uses an openssl which is marked insecure). Might have to migrate a database 2. lots of settings now use RFC 42-style settings, which might contain new typos 3. this updates uffd (& changes the patches we apply). Since version dependencies of uffd are basically "whatever debian has" we have never bothered to match them, but afaik have also never updated uffd since the initial deploy some years ago. No guarantee it still works. 4. tracktrain depends on haskellPackages.conferer-warp, which is currently marked broken. There is no reason for this (it builds fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1. cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a merge of haskell-updates into 23.05
2023-06-06 00:04:11 +00:00
}
},
update inputs; simple-nixos-mailserver now has a 23.11 branch
2024-01-08 21:21:05 +00:00
"nixpkgs-23_11": {
"locked": {
update inputs
2024-01-30 13:46:02 +00:00
"lastModified": 1706098335,
"narHash": "sha256-r3dWjT8P9/Ah5m5ul4WqIWD8muj5F+/gbCdjiNVBKmU=",
update inputs; simple-nixos-mailserver now has a 23.11 branch
2024-01-08 21:21:05 +00:00
"owner": "NixOS",
"repo": "nixpkgs",
update inputs
2024-01-30 13:46:02 +00:00
"rev": "a77ab169a83a4175169d78684ddd2e54486ac651",
update inputs; simple-nixos-mailserver now has a 23.11 branch
2024-01-08 21:21:05 +00:00
"type": "github"
},
"original": {
"id": "nixpkgs",
"ref": "nixos-23.11",
"type": "indirect"
}
},
keep using the old uffd's pythonPackages, lol
2023-09-27 15:14:05 +00:00
"nixpkgs-oldstable": {
"locked": {
"lastModified": 1678761643,
"narHash": "sha256-tapXZvg6Kg5Fm7Fm6i+7cRC5Exp2lX7cgMrqsfrGhuc=",
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "c4aec3c021620d98861639946123214207e98344",
"type": "github"
},
"original": {
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "c4aec3c021620d98861639946123214207e98344",
"type": "github"
}
},
mattermost: 8.1.10 → 9.5.1 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
2024-02-21 16:38:40 +00:00
"nixpkgs-unstable": {
"locked": {
update inputs
2024-04-15 19:58:05 +00:00
"lastModified": 1713201277,
"narHash": "sha256-xHxbvpjepaDEc3DxJNMCWOFyBqW7yIANbUU+yWSL9+c=",
mattermost: 8.1.10 → 9.5.1 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
2024-02-21 16:38:40 +00:00
"owner": "NixOS",
"repo": "nixpkgs",
update inputs
2024-04-15 19:58:05 +00:00
"rev": "fc69edccf533e2731ab8850c59482907e0d4fc28",
mattermost: 8.1.10 → 9.5.1 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
2024-02-21 16:38:40 +00:00
"type": "github"
},
"original": {
"id": "nixpkgs",
switch to nixpkgs-small channels these get more frequent updates, but we might (sometimes) wind up having to build stuff ourselves that hydra hasn't gotten to yet.
2024-04-08 23:20:24 +00:00
"ref": "nixos-unstable-small",
mattermost: 8.1.10 → 9.5.1 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
2024-02-21 16:38:40 +00:00
"type": "indirect"
}
},
remove unstable this downgrades vaultwarden back to what's in stable; this was the last thing we used from unstable, so remove that as well.
2023-09-27 21:22:15 +00:00
"nixpkgs_2": {
"locked": {
update inputs
2024-04-15 19:58:05 +00:00
"lastModified": 1713180868,
"narHash": "sha256-5CSnPSCEWeUmrFiLuYIQIPQzPrpCB8x3VhE+oXLRO3k=",
remove unstable this downgrades vaultwarden back to what's in stable; this was the last thing we used from unstable, so remove that as well.
2023-09-27 21:22:15 +00:00
"owner": "NixOS",
"repo": "nixpkgs",
update inputs
2024-04-15 19:58:05 +00:00
"rev": "140546acf30a8212a03a88ded8506413fa3b5d21",
remove unstable this downgrades vaultwarden back to what's in stable; this was the last thing we used from unstable, so remove that as well.
2023-09-27 21:22:15 +00:00
"type": "github"
},
"original": {
"id": "nixpkgs",
switch to nixpkgs-small channels these get more frequent updates, but we might (sometimes) wind up having to build stuff ourselves that hydra hasn't gotten to yet.
2024-04-08 23:20:24 +00:00
"ref": "nixos-23.11-small",
remove unstable this downgrades vaultwarden back to what's in stable; this was the last thing we used from unstable, so remove that as well.
2023-09-27 21:22:15 +00:00
"type": "indirect"
}
},
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"nixpkgs_3": {
remove unstable this downgrades vaultwarden back to what's in stable; this was the last thing we used from unstable, so remove that as well.
2023-09-27 21:22:15 +00:00
"locked": {
update inputs
2024-04-15 19:58:05 +00:00
"lastModified": 1712883908,
"narHash": "sha256-icE1IJE9fHcbDfJ0+qWoDdcBXUoZCcIJxME4lMHwvSM=",
remove unstable this downgrades vaultwarden back to what's in stable; this was the last thing we used from unstable, so remove that as well.
2023-09-27 21:22:15 +00:00
"owner": "NixOS",
"repo": "nixpkgs",
update inputs
2024-04-15 19:58:05 +00:00
"rev": "a0c9e3aee1000ac2bfb0e5b98c94c946a5d180a9",
remove unstable this downgrades vaultwarden back to what's in stable; this was the last thing we used from unstable, so remove that as well.
2023-09-27 21:22:15 +00:00
"type": "github"
},
"original": {
"owner": "NixOS",
"ref": "nixpkgs-unstable",
"repo": "nixpkgs",
"type": "github"
}
},
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"root": {
"inputs": {
flake: add deploy-rs
2022-11-13 22:04:55 +00:00
"deploy-rs": "deploy-rs",
reduce lockfile size
2022-11-25 21:48:27 +00:00
"nixos-mailserver": "nixos-mailserver",
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"nixpkgs": "nixpkgs_2",
keep using the old uffd's pythonPackages, lol
2023-09-27 15:14:05 +00:00
"nixpkgs-oldstable": "nixpkgs-oldstable",
mattermost: 8.1.10 → 9.5.1 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
2024-02-21 16:38:40 +00:00
"nixpkgs-unstable": "nixpkgs-unstable",
sops-nix proof of concept this is currently deployed and appears to be working. please everyone have a look at it & then decide if we want to use this for the other secrets as well.
2023-04-19 18:08:45 +00:00
"sops-nix": "sops-nix",
init tracktrain
2023-01-22 01:25:07 +00:00
"tracktrain": "tracktrain"
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
}
},
"sops-nix": {
"inputs": {
remove nix-hexchen from flake inputs fun fact: this commit delets more lines (in flake.lock) than were removed during the previous commits (to vendor nix-hexchen's modules into our repo)
2024-02-18 12:45:32 +00:00
"nixpkgs": "nixpkgs_3",
sops-nix proof of concept this is currently deployed and appears to be working. please everyone have a look at it & then decide if we want to use this for the other secrets as well.
2023-04-19 18:08:45 +00:00
"nixpkgs-stable": [
"nixpkgs"
]
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
},
"locked": {
update inputs
2024-04-15 19:58:05 +00:00
"lastModified": 1713174909,
"narHash": "sha256-APoDs2GtzVrsE+Z9w72qpHzEtEDfuinWcNTN7zhwLxg=",
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"owner": "Mic92",
"repo": "sops-nix",
update inputs
2024-04-15 19:58:05 +00:00
"rev": "cc535d07cbcdd562bcca418e475c7b1959cefa4b",
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"type": "github"
},
"original": {
"owner": "Mic92",
"repo": "sops-nix",
"type": "github"
}
},
initial work for 23.05 in theory this might be ready to deploy. Potential hazards & things to know when actually doing so: 1. the mysql version used by mattermost was updated (the old uses an openssl which is marked insecure). Might have to migrate a database 2. lots of settings now use RFC 42-style settings, which might contain new typos 3. this updates uffd (& changes the patches we apply). Since version dependencies of uffd are basically "whatever debian has" we have never bothered to match them, but afaik have also never updated uffd since the initial deploy some years ago. No guarantee it still works. 4. tracktrain depends on haskellPackages.conferer-warp, which is currently marked broken. There is no reason for this (it builds fine). Until fixed upstream, build with NIXPKGS_ALLOW_BROKEN=1. cf. https://github.com/NixOS/nixpkgs/pull/234784; waiting for a merge of haskell-updates into 23.05
2023-06-06 00:04:11 +00:00
"systems": {
"locked": {
"lastModified": 1681028828,
"narHash": "sha256-Vy1rq5AaRuLzOxct8nz4T6wlgyUR7zLU309k9mBC768=",
"owner": "nix-systems",
"repo": "default",
"rev": "da67096a3b9bf56a91d16901293e51ba5b49a27e",
"type": "github"
},
"original": {
"owner": "nix-systems",
"repo": "default",
"type": "github"
}
},
init tracktrain
2023-01-22 01:25:07 +00:00
"tracktrain": {
"flake": false,
"locked": {
tracktrain: update This is the initial version for this year's run of absurd train operations. I won't dare to call it a release for at least another month or so, so no version number. Changes done in our nixfiles: - tracktrain now needs ntfy-sh so people (read: I) can get push notifications if things break or at least look a little weird - I removed the grafana instance; seems like somewhere in the last year they changed how to host it under a sub-path (ours was at /metrics), so it broke, and I'm not feeling any particular urge to fix it - last year's database contents have been yoten - also manually updated the gtfs (though I intend to implement logic for fetching it in tracktrain, I first need to drag Ilztalbahn into actually publishing up-to-date versions again first)
2024-05-01 02:08:16 +00:00
"lastModified": 1714552989,
"narHash": "sha256-I/Lml1AWvuvnFqlzJ017MymKTD2N1oGwNu2eEf6K/O4=",
init tracktrain
2023-01-22 01:25:07 +00:00
"ref": "main",
tracktrain: update This is the initial version for this year's run of absurd train operations. I won't dare to call it a release for at least another month or so, so no version number. Changes done in our nixfiles: - tracktrain now needs ntfy-sh so people (read: I) can get push notifications if things break or at least look a little weird - I removed the grafana instance; seems like somewhere in the last year they changed how to host it under a sub-path (ours was at /metrics), so it broke, and I'm not feeling any particular urge to fix it - last year's database contents have been yoten - also manually updated the gtfs (though I intend to implement logic for fetching it in tracktrain, I first need to drag Ilztalbahn into actually publishing up-to-date versions again first)
2024-05-01 02:08:16 +00:00
"rev": "203d9555b6915d834e9107db4e4ccfa5c99c3631",
"revCount": 101,
init tracktrain
2023-01-22 01:25:07 +00:00
"type": "git",
"url": "https://stuebinm.eu/git/tracktrain"
},
"original": {
"ref": "main",
"type": "git",
"url": "https://stuebinm.eu/git/tracktrain"
}
},
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"utils": {
update inputs
2023-12-23 02:56:55 +00:00
"inputs": {
"systems": "systems"
},
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"locked": {
update inputs
2023-12-23 02:56:55 +00:00
"lastModified": 1701680307,
"narHash": "sha256-kAuep2h5ajznlPMD9rnQyffWG8EM/C73lejGofXvdM8=",
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"owner": "numtide",
"repo": "flake-utils",
update inputs
2023-12-23 02:56:55 +00:00
"rev": "4022d587cbbfd70fe950c1e2083a02621806a725",
shoehorn nix-hexchen-style config into flakes 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"
2022-11-13 21:45:50 +00:00
"type": "github"
},
"original": {
"owner": "numtide",
"repo": "flake-utils",
"type": "github"
}
}
},
"root": "root",
"version": 7
}
Reference in a new issue Copy permalink