- Native packages are at [packages](./packages/default.nix)
- Existing Nixpkgs packages are patched at [overlay](./overlay/default.nix)
- Tests are at [tests](./tests/default.nix) (messy)
# Contributing
At the moment every user needs to also act as distro developer, designing how
packaging works needs to be done before packages can be submitted in bulk.
Patches can be submitted and issues reported via the
[mailing list](https://lists.sr.ht/~ehmry/genodepkgs). The mailing list is the
minimum viable mechanism for community development, and may be replaced later.
@ -31,36 +37,23 @@ The worksites at the moment are:
- Documentation
- Port tests to the NixOS test harness.
- ARM, i686
- Patching standard Nixpkgs packages via an overlay. Workflow and tooling
needs to be explored for building emulated UNIX environments.
- Write a proper test framework, or better, reuse the NixOS one.
- Patching standard Nixpkgs packages by overlay. Explore Workflow and tooling
for building emulated UNIX environments.
- LLVM testing and upstreaming patches.
- Formalizing Dhall configuration types.
- Configuration validation via a service routing prover.
# Packaging
Packaging is done using standard Nixpkgs methods, a `stdenv` is available for
cross-compilation. See [Solo5](./packages/solo5/default.nix) as an example.
# System description format
The high-level interface to system building are boot descriptions. These Dhall
documents describe the configuration of an [Init](https://genode.org/documentation/genode-foundations/19.05/system_configuration/The_init_component.html)
instance and a store of ROM (Read-Only Memory) modules. These description can be
used to build firmware-like binary images or merged and nested within other
descriptions. In theory these descriptions can arrange file-systems, but those
The high-level interface to system building are boot descriptions. These Dhall
documents describe the configuration of an [Init](https://genode.org/documentation/genode-foundations/19.05/system_configuration/The_init_component.html)
instance and a store of ROM (Read-Only Memory) modules. These description can be
used to build firmware-like binary images or merged and nested within other
descriptions. In theory these descriptions can arrange file-systems, but those