What are your goals for 20.03?

In a similar vein to What are your goals for 19.09?, what are some peoples goals for the upcoming stable release?


Guess I’ll start then :slight_smile:

Also had a pipe dream for adding support for using “manylinux1” python wheels, https://github.com/NixOS/nixpkgs/issues/71935


Thanks for kicking this off @jonringer :smile:

My goal for 20.03 is a refactor of the httpd module, which I have started on. Currently I’m working on a PR to modify services.httpd.virtualHosts from being a listOf submodule (...) to an attrsOf submodule (...), which will allow for fun options that mimic nginx, like enableACME.


Currently the NixOS manual uses services.httpd for several examples. This module isn’t a very good example for several reasons, but specifically the Abstractions section gives examples which no longer are true with my change. I was hoping someone with better documentation skills than my own might consider rewriting the services.httpd examples in that section to use another module as an example. HELP WANTED :wink:

Also, much like I was hoping for 19.09 I am still hoping the security.acme.certs module will be expanded/rewritten to support dns challenges, which @petabyteboy is already working on :tada:


Aside from that… NixOS works really well for me these days, so nothing else is really jumping out at me yet. If anything catches my attention before the next release I’ll be sure to revise my post.


For now my goals for 20.03 are cleaning up the virtual console options (#71473) and deprecating the loaOf type (#63103). Then intend to rewrite the plugin system for rxvt-unicode, I’d like for it to be easy configurable like it is for vim and other packages.

Also, more of a wish than an actual goal: using p11kit to make firefox and chromium use the real certificates store (issue #8247).


Getting the initial mastodon packaging and module through would be really awesome.
Also the acme DNS challenge support @aanderse mentioned would be great.


Probably won’t have a ton of time to do all the things I want to do as usual, but the top of my list are at the moment:

  • Improving Crystal packaging a bit more.

    • Adding a bunch of Crystal apps to nixpkgs (got drvs for icr, ameba, and lucky).
    • Also would be nice to get static binaries going without having arcane knowledge.
    • Removing the dependency on the compiler at runtime.
    • Maybe bootstrapping all the Crystal versions back to the first one, so we don’t rely on binary blobs as much.
  • Continue work on the graphical NixOS installer. We started it during the NixCon and at least it is able to install in qemu now.

    • It needs some love to be able to select reasonable default configurations and packages/modules.
    • Also the installation step itself provides no visible feedback, which may cause people to think it crashed.
    • You can take a look at it via GitHub - Lucus16/calamares at os-modules but it still lacks documentation and should be extracted to nixpkgs or a nix-community repo.
  • Automating updates of the gems in ruby.withPackages, at least for security issues.


Finish cleaning up the BEAM ecosystem. Mostly:

  • Moving Elixir and LFE to interpreters
  • Offering a build system for BEAM that use the lockfile directly. Probably inspired from buildGoModule for now, allowing to use BEAM normal tooling with sandboxing.
  • Make the documentation for the BEAM ecosystem more oriented toward every day use.
  • Upgrading Riak to a newer version so that…
  • I can drop the support for the R16 basho BEAM. This is now totally out of support and we need to drop it.

EDIT: Also fix the double addition into path of the elixir beam modules. I do not know where it come from and it has no real impact on prod, but it generates tons of warning at every use of elixir which is painful as hell.


Mostly reproducibility focused:

  • Minimal ISO reliably 100% reproducible
  • disorderfs support for r13y.com

I would also like it to be very easy to set up a robust whole internet wireguard vpn using just nix.


Update: i was calling victory too fast on riak being updated to avoid the basho erlang fork. Riak is not yet ready for it. At that point i want to drop Riak in the meantime but i understand that it may be a no

The virtual console changes and loaOf deprecation have been merged! I’ve also just finished the revamp of urxvt plugins system (PR # 77347). Pretty happy with how things are coming for 20.03.


Let me know and/or @disassembler if there’s anything else you think we should push for 20.03 that you’d like to contribute :sparkles:


Thank you! The next thing would be the matter of pango and bitmap fonts, this should be done before 20.03 for sure. I need some help on that, though: there’s too many packages and I’m not 100% sure what I’m doing is corrent.

I would like to see the PR below merged to improve the flexibility of the auto-upgrade service.
This PR allows to define a reboot window during which a server can be rebooted. By doing so, you avoid a critical server being rebooted outside it’s maintenance window.

I currently use this because I administer many remote systems, some of which are turned on and off daily, others running 24/7. I defined two moments for the auto upgrade, one at night and on during the day (performing a nixos-rebuild boot, not switch), to catch both situations. But reboots are only allowed during the night. Like this, in both cases the servers will receive updates and will reboot when required, either by the service during the night, or because they are manually rebooted daily.

Feel free to review if you would like to see this merged!



I want to get my swap / rngd patches into unstable before the branch-off to fix an entropy starvation with an encrypted swap partition I observe on my system.
Current status is works-for-me™, but could benefit from some more eyes looking at it and some tests.

done: dotnet-sdk: Allow multiple packages by baracoder · Pull Request #73262 · NixOS/nixpkgs · GitHub

(Can’t edit original post :()

@SRGOM most of azure runs on linux now. I switched over as my daily driver because HyperV was pretty unsatisfactory, and then one day decided to corrupt all my linux vhd’s. It is probably very dependent on the team as well.