nixpkgs/nixos
eljamm 6f35a68586 nixos/libeufin: init module
nixos/libeufin: init module

nixos/libeufin(nexus): init submodule

nixos/libeufin(nexus): refactor service

Also added state directory to allow the creation of client ebic keys.

nixos/libeufin: review suggestions

nixos/libeufin: fix nexus service executable

nixos/libeufin: add mkLibeufinModule

nixos/libeufin: fix dbinit service not starting for utils, cleanup

nixos/libeufin: use mkLibeufinModule for nexus

nixos/libeufin: use mkLibeufinModule for bank

nixos/libeufin: add initialAccounts, stateDir options

nixos/libeufin: refactor to make nexus work, cleanup

nixos/libeufin: refactor stateDir, only register accounts on init

nixos/libeufin: explicitly specify psql user

Sometimes the dbinit service fails to find the user.

nixos/libeufin: cleanup stateDir

nixos/libeufin: add openFirewall option; install package

feat: apply review suggestions

Co-authored-by: h7x4 <h7x4@nani.wtf>

style: format code

fix: evaluation errors

fix(libeufin): start main services after dbinit

The main services can start after their databases have been initialized,
it's just that the bank and nexus shouldn't do the initialization at the
same time.

refactor(libeufin): dbinit script

feat: add assertions, remove throw

chore: remove unused code

feat(libeufin): recfactor dbinit service

feat: move libeufin module to services/finance

refactor(libeufin): remove configFile option

refactor(libeufin): use environment.etc for config file
2025-01-13 09:03:30 +01:00
..
doc/manual himalaya: 1.0.0-beta.4 -> 1.1.0 (#373026) 2025-01-12 23:20:47 +01:00
lib nixos-test-driver: reformat with latest ruff 2025-01-09 15:43:10 +01:00
maintainers openstack-image-zfs: use system.build.image 2024-12-16 15:35:21 +01:00
modules nixos/libeufin: init module 2025-01-13 09:03:30 +01:00
tests mattermost: allow overriding the webapp easily (#373085) 2025-01-13 07:19:24 +01:00
COPYING
default.nix treewide: format all inactive Nix files 2024-12-10 20:26:33 +01:00
README.md docs: remove outdated references to CODEOWNERS 2024-12-30 22:08:49 +00:00
release-combined.nix Revert "nixosTests.gitlab: do not block nixos-unstable on aarch64" 2025-01-04 15:07:41 +01:00
release-small.nix treewide: format all inactive Nix files 2024-12-10 20:26:33 +01:00
release.nix iso-image: fix output filename 2025-01-08 14:35:07 +01:00

NixOS

NixOS is a Linux distribution based on the purely functional package management system Nix. More information can be found at https://nixos.org/nixos and in the manual in doc/manual.

Testing changes

You can add new module to your NixOS configuration file (usually its /etc/nixos/configuration.nix). And do sudo nixos-rebuild test -I nixpkgs=<path to your local nixpkgs folder> --fast.

Commit conventions

  • Make sure you read about the commit conventions common to Nixpkgs as a whole.

  • Format the commit messages in the following way:

    nixos/(module): (init module | add setting | refactor | etc)
    
    (Motivation for change. Link to release notes. Additional information.)
    

    Examples:

    • nixos/hydra: add bazBaz option

      Dual baz behavior is needed to do foo.

    • nixos/nginx: refactor config generation

      The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).

Reviewing contributions

When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break peoples installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.

Module updates

Module updates are submissions changing modules in some ways. These often contains changes to the options or introduce new options.

Reviewing process:

  • Ensure that the module maintainers are notified.
    • The continuous integration system will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
  • Ensure that the module tests, if any, are succeeding.
    • You may invoke OfBorg with @ofborg test <module> to build nixosTests.<module>
  • Ensure that the introduced options are correct.
    • Type should be appropriate (string related types differs in their merging capabilities, loaOf and string types are deprecated).
    • Description, default and example should be provided.
  • Ensure that option changes are backward compatible.
    • mkRenamedOptionModuleWith provides a way to make renamed option backward compatible.
    • Use lib.versionAtLeast config.system.stateVersion "24.05" on backward incompatible changes which may corrupt, change or update the state stored on existing setups.
  • Ensure that removed options are declared with mkRemovedOptionModule.
  • Ensure that changes that are not backward compatible are mentioned in release notes.
  • Ensure that documentations affected by the change is updated.

Sample template for a module update review is provided below.

##### Reviewed points

- [ ] changes are backward compatible
- [ ] removed options are declared with `mkRemovedOptionModule`
- [ ] changes that are not backward compatible are documented in release notes
- [ ] module tests succeed on ARCHITECTURE
- [ ] options types are appropriate
- [ ] options description is set
- [ ] options example is provided
- [ ] documentation affected by the changes is updated

##### Possible improvements

##### Comments

New modules

New modules submissions introduce a new module to NixOS.

Reviewing process:

  • Ensure that all file paths fit the guidelines.
  • Ensure that the module tests, if any, are succeeding.
  • Ensure that new module tests are added to the package passthru.tests.
  • Ensure that the introduced options are correct.
    • Type should be appropriate (string related types differs in their merging capabilities, loaOf and string types are deprecated).
    • Description, default and example should be provided.
  • Ensure that module meta field is present
    • Maintainers should be declared in meta.maintainers.
    • Module documentation should be declared with meta.doc.
  • Ensure that the module respect other modules functionality.
    • For example, enabling a module should not open firewall ports by default.

Sample template for a new module review is provided below.

##### Reviewed points

- [ ] module path fits the guidelines
- [ ] module tests, if any, succeed on ARCHITECTURE
- [ ] module tests, if any, are added to package `passthru.tests`
- [ ] options have appropriate types
- [ ] options have default
- [ ] options have example
- [ ] options have descriptions
- [ ] No unneeded package is added to `environment.systemPackages`
- [ ] `meta.maintainers` is set
- [ ] module documentation is declared in `meta.doc`

##### Possible improvements

##### Comments