Kudos to all involved! 
Has anyone experienced any issues with updating/changing the channel from 18.03?
Hi. I have successfully changed my channel and rebuild the system, but not yet booted into the new system (nixos-rebuild boot). I guess I will do that later today though.
I have migrated several systems during the 18.09 beta without major issues. I think a deprecated option was the biggest hassle.
I didn’t have a system on 16.09 or older though.
Edit: some services don’t restart correctly when switching on a running system (I think mainly virtual box related stuff), but I didn’t expect it to. So using ‘nixos-rebuild boot’ would be better for my systems. I’m not sure if this is the recommended way.
I may be biased as I would have fixed anything stopping an upgrade, but I did not have any issues upgrading! I upgraded a mission-critical machine of mine (work laptop) two weeks before branch-off to nixos-unstable and I didn’t need to change a thing except remove some patches to bluez and pulseaudio (they were now upstreamed).
Thank you all for the hard work, especially release managers. If you two at NixCon, beers (or other beverage you prefer) are on me 
I did experience issues. 
Version 18.09 includes openssh 7.7p1 which breaks the -w option, which is used by NixOps to make encrypted connections between machines. So I have to downgrade to 18.03 to keep things working.
See Tunnel device forwarding (-w) broken in openssh 7.7p1, major issue for NixOps · Issue #48016 · NixOS/nixpkgs · GitHub for details.
This was fixed several days ago, by the way.
Uneventful is how I would describe the upgrade. The things that stopped working were insignificant.
I am just missing a few packages (issues exist for those), but otherwise NixOS is mostly delivering what I was looking for.
I consider the lack of community shared infrastructure to run automation (like ryan’s bot) and the lack of tooling to completely fork the NixOS project a large project risk. It would be great if that could be taken seriously.
So, I would be interested in a command deployFullNixOSInfrastructure which would do everything given e.g. an Amazon account id and possibly a certificate for some domain to run the full NixOS infrastructure, including its website, Hydra, etc. It’s not that I want to run all that, but it’s more that I would like to have the option.
Booted up my 18.09 desktop today to see rofi, termite and polybar to render pink and hardly usable. I’m using services.xserver = { videoDrivers = [ "amdgpu" ]; deviceSection = ''Option "TearFree" "true"; } for an RX 480. Did this happen to someone else?
Rolled back to an 18.03 generation in the meantime.
Ok, another breakage found. I no longer have access to Perl modules for which packages are included in environment.systemPackages.
In 18.03, I have the following paths in @INC:
(per-user paths removed)
/nix/var/nix/profiles/default/lib/perl5/site_perl
/run/current-system/sw/lib/perl5/site_perl/5.24.3/x86_64-linux-thread-multi
/run/current-system/sw/lib/perl5/site_perl/5.24.3
/run/current-system/sw/lib/perl5/site_perl
/nix/store/l6qc2aa8vf6sxpmi7cw28nrihhmmmvp5-perl-5.24.3/lib/perl5/site_perl/5.24.3/x86_64-linux-thread-multi
/nix/store/l6qc2aa8vf6sxpmi7cw28nrihhmmmvp5-perl-5.24.3/lib/perl5/site_perl/5.24.3
/nix/store/l6qc2aa8vf6sxpmi7cw28nrihhmmmvp5-perl-5.24.3/lib/perl5/5.24.3/x86_64-linux-thread-multi
/nix/store/l6qc2aa8vf6sxpmi7cw28nrihhmmmvp5-perl-5.24.3/lib/perl5/5.24.3
.
In 18.09, it’s just:
/nix/store/q9ajsngf2w3r10dg7b1148wzq1avp4gj-perl-5.28.0/lib/perl5/site_perl/5.28.0/x86_64-linux-thread-multi
/nix/store/q9ajsngf2w3r10dg7b1148wzq1avp4gj-perl-5.28.0/lib/perl5/site_perl/5.28.0
/nix/store/q9ajsngf2w3r10dg7b1148wzq1avp4gj-perl-5.28.0/lib/perl5/5.28.0/x86_64-linux-thread-multi
/nix/store/q9ajsngf2w3r10dg7b1148wzq1avp4gj-perl-5.28.0/lib/perl5/5.28.0
The /run/current-system/sw/ paths are no longer there, so the installed packages are not visible to Perl.
I know I should create an issue about this, but I don’t have time right now.
Turns out this was caused by compton and is a known issue with mesa 18. Temporary workarounds are to use the xrender backend or specify allow_rgb10_configs=false as an ENV variable.
Could you make a PR with this? I don’t have the hardware to reproduce but it would be nice to fix this for users. Hopefully it is just adding the var to this line:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/x11/compton.nix#L242
I could do that. But what is the easiest way of using a nixpkgs fork in /etc/nixos/configuration.nix so I can test it?
nixos-rebuild switch -I nixpkgs=path/to/your/nixpkgs
I’ve made a PR at nixos/compton: fix corrupt colours with Mesa 18 on AMD by tmplt · Pull Request #48689 · NixOS/nixpkgs · GitHub.
It went pretty smooth for me as well. I haven’t stumbled upon any issues (yet).
found an issue: This happens again:https://github.com/NixOS/nixpkgs/issues/24563
Work-around is in this comment.