I’m happy to announce that on September 36th,^W 18.09 “Jellyfish” has hit stable! As with previous releases, x86_64-linux and x86_64-darwin are the main focus of the community, and the main supported platforms, but the aarch64-linux platform is in pretty good shape I’d say.
Since 18.03 there over 21k commits! (16k when removing merge commits). The contributors sure are working hard! 819 commit authors for this release! Thanks to all of you for the hard work!
Please, see the release notes at least for 18.09 highlights:
Note that 18.03 is expected to receive important fixes at least until the end of October. Further support is not guaranteed, and shouldn’t be expected.
Let’s see who’s leading the scoreboard this time around:
First of all: Thank you all for this awesome release!
Second: Call for maintainer(s): I am currently on a sabatical and during my trip I have only sometimes internet connection and almost never a connection which is good enough for updating a distro (e.g.: I have send email via a 120 B/s connection from Yukon, Watson Lake, Canada).
So what I am asking is that someone maintains 18.03. for critical security updates until February 2019. All I care about is openssl and kernel updates (I’m running 4.14 LTS). My machine is not strong enough for building that stuff on my own, so I’m asking here whether someone would be so kind and maintain the 18.03 branch and backport fixes to these two mission-critical packages for me.
I hope someone does this.
Best regards,
Matthias
PS: For context: I’m on home-vacation right now and will continue my journey mid-november. My notebook, though, is not here with me in Germany but with my dad, who is still on the trip. I will go back in November and we will be mostly off the grid, that’s why I’m asking… feel free to ask me questions here, via PM or via mail.
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).
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.
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.
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:
