NixOS 19.03 feature freeze

Hi all!

The time for a new NixOS release is approaching us once again. The release of NixOS 19.03 “Koi” will be managed by @samueldr and myself. This year, we’re aiming for a feature freeze and branch-off on the 25th of February in order to get a release* within March.

Some of the changes to look forward to from 18.09:

  • Build everything with GCC 8 by default, thanks to lots of work from @fpletz and @globin Commits · NixOS/nixpkgs · GitHub
  • Linux 4.19 by default, already in master!
  • Your change here! If you have anything big that you want to get into the release, please let us know (@lheckemann and @samueldr on GitHub), especially if you’re not sure if it’ll be in master by then.

Between the 25th of February and the release, we will be working towards Zero Hydra Failures and starting the regular release maintenance work, backporting minor bugfixes and security patches.

Looking forward to working with you for a wonderful release!

Linus

*Releasing actual koi into the wild may damage ecosystems and be illegal in your jurisdiction. Please don’t do this.

21 Likes

One feature I’ve been working on is less reliance on nscd for caching because it broke systemd dynamic users. Caching now is only used for positive lookups of DNS names, all other forms I’ve already disabled. This fixed some issues with NixOS laptops sometimes not being able to browse the web when roaming.

I want to get rid of the nscd caching totally, by replacing the name lookup cache with systemd-resolved. Nscd is then purely a proxy for resolving NSS modules in the nix store. It should eliminate a lot of caching related bugs that we’ve faced before.

Also I would like to see a new version of systemd for 19.03, as there were issues with Cgroups V2 not working well with nixos-containers that have been fixed. This could allow people to opt in to Cgroups v2 without issues.

9 Likes

It would be great if we also can manage to switch from C to C.utf-8 locales in stdenv and our glibc package as many applications now expect unicode locales (i.e. python). Debian and Fedora are already on board with this. Also since systemd has now support for that too

UPDATE Tracking issue: glibc: C.UTF-8 locales by Mic92 · Pull Request #54485 · NixOS/nixpkgs · GitHub

10 Likes

I would love to have some ways to specify dependencies between packages and kernel (if you enable qemu => enable virtualisation knobs in kernel’s Kconfig or at least emit a warning) as is done in: [RFC] add ability to merge structured configs by teto · Pull Request #42838 · NixOS/nixpkgs · GitHub .
I am also cleaning up [RFC] get lua support closer to python by teto · Pull Request #33903 · NixOS/nixpkgs · GitHub and splitting it into smaller PRs so that the lua ecosystem works as python’s withPackages.

Could someone look at this PR: llvmPackages: 5 -> 7 on Linux, keep Darwin at 5 until fixed by dtzWill · Pull Request #49402 · NixOS/nixpkgs · GitHub

I’m looking for feedback on better support for logrotate in 19.03.

https://github.com/NixOS/nixpkgs/pull/54529

I’d like to create logrotate rules by default for enabled services like apache, etc… like other distros do, or at bare minimum document the need to rotate logs.
Users coming from Debian can be surprised to find out their logs continue to grow indefinitely instead of being rotated automatically like they are on Debian.

I’m willing to do the work on this, but would like to hear any opinions that people have before I start.

2 Likes

feedback on better support for logrotate in 19.03

Personally I don’t see a need as most services are logging through the journal which handles this for us.

1 Like

Hi Peter,

Yeah for desktop use case there isn’t anything to turn on for logrotate usually, as it is covered by journald as you mentioned.

I’m thinking for people who enable services which are not covered by journald.

The 2 use cases I have in mind are apache and rsyslog. I think there is value in automatically rotating those logs for users, like Debian does, or at least making mention in the documentation that the user needs to set up log rotation as most users would expect this to already be in place.

2 Likes

5 posts were merged into an existing topic: Nginx logging to journald

Another things some might not be aware:

We have a milestone for 19.03 to track issues features and fixes we want included in 19.03. You can see a list of them on GitHub under the 19.03 milestone:

These are sometimes more manageable to try to help out on compared to random ones from the global issue tracker.

4 Likes

I’ve created another thread to discuss nginx’s logging behavior: Nginx logging to journald

2 Likes

Can we have something that manages users .files ? I know we can use diff tools but is much nicer to have in declarative way.

GitHub - nix-community/home-manager: Manage a user environment using Nix [maintainer=@rycee] has a nixos module at https://github.com/rycee/home-manager/blob/c18984c452013ff0edb3d67ab0a1a245333dd4ce/nixos/default.nix.

1 Like

Thx for the links I am very much aware of home-manager, the problem is this solution is not integrated with nixos and required separate installation.

I’m afraid I can’t see how that is a problem.

1 Like

Did you switch 19.03 to back to kernel 4.14.98?

[root@nixtn:~]$ ls -l /nix/store/cgv2y5ghannrswkkk299mwrwhi70xik3-nixos-system-nixtn-19.03pre168725.64825dfd26a
...
lrwxrwxrwx 1 root root    65  1. Jan 1970  kernel -> /nix/store/1spnrykkf4dsahg5bd6p1szmk13v3a9i-linux-4.14.98/bzImage
...

Which points to a 4.14.98 kernel.

Just to make sure, it’s really 19.03:

[root@nixtn:~]$ cat /nix/store/cgv2y5ghannrswkkk299mwrwhi70xik3-nixos-system-nixtn-19.03pre168725.64825dfd26a/nixos-version 
19.03pre168725.64825dfd26a

Yes, there is a regression in 4.19, see #54509; our work-around caused that other sneaky regression.

It would be nice to have purescript and taffybar building again. They worked in 18.09.

The taffybar issue was fixed upstream and has made it into haskell-updates. I’m not sure what the process is for getting that merged.

Purescript was broken by a GHC upgrade and has an open PR to fix it.

I would like to have the extended tinydns module reviewed/integrated in the new release.