No attempt on x86_64-darwin (full log)

The following builds were skipped because they don't evaluate on x86_64-darwin: rpcbind

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)

Attempted: rpcbind

shrinking RPATHs of ELF executables and libraries in /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5
shrinking /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5/bin/rpcinfo
shrinking /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5/sbin/rpcbind
gzipping man pages under /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5/share/man/
strip is /nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5/bin  /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5/sbin
patching script interpreter paths in /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5
checking for references to /build in /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5...
moving /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5/sbin/* to /nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5/bin
/nix/store/wl45ainzhq8awxdbps4rn9kznnhz3s66-rpcbind-1.2.5

Success on aarch64-linux (full log)

Attempted: rpcbind

shrinking RPATHs of ELF executables and libraries in /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5
shrinking /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5/sbin/rpcbind
shrinking /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5/bin/rpcinfo
gzipping man pages under /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5/share/man/
strip is /nix/store/y4ymnvgxygpq05h03kyzbj572zmh6zla-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5/bin  /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5/sbin
patching script interpreter paths in /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5
checking for references to /build in /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5...
moving /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5/sbin/* to /nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5/bin
/nix/store/p0cag9qffvlh1dnj2c7m4jygscbyl5mc-rpcbind-1.2.5

For reference: The 2 IRC users that had trouble updating to Nix 2.0:

• floop, 2018-09-06, logs, default.nix: More thoroughly explain the macOS upgrade process #46207
• gudea, 2018-09-08, logs, Impossible to easily upgrade NixOS from <=17.09 to 18.09 #46387

Also: A Nix 2.0 nix.conf apparently isn't backwards compatible with one for Nix 1.x. The second user received an additional error because of that when they tried to use the Nix 2.0 client on their NixOS 17.09 system. Inlined pastebin of their error:

√ nix upgrade-nix
[0.0 MiB DL] downloading 'https://github.com/NixOS/nixpkgs/raw/master/nixos/modules/installer/tools/nix-fallback-paths.nix'warning: unknown setting 'signed-binary-caches'
[0.0 MiB DL]
warning: unknown setting 'signed-binary-caches'
replacing old 'nix-2.1.1'
installing 'nix-2.1.1'
building path(s) ‘/nix/store/q37gn45a3ylpjghkfcvnla7hs5yg1jym-user-environment’
error: unsupported builtin function ‘buildenv’
builder for ‘/nix/store/ddq105fnqkda93kdl4p436h96c4fan5c-user-environment.drv’ failed with exit code 1
error: build of ‘/nix/store/ddq105fnqkda93kdl4p436h96c4fan5c-user-environment.drv’ failed
error: program '/nix/store/h180y3n5k1ypxgm1pcvj243qix5j45zz-nix-2.1.1/bin/nix-env' failed with exit code 100

Yes, I think that's the error you get when you try to use nix upgrade-nix with an older daemon running.

The whole daemon/client mismatch confusion should really be dealt with better in general if we're forcing people to upgrade.

As a rule, we should make sure it is always be possible to upgrade yearly,

I don't think we should do this.

How many users do we think this is relevant for? I would assume a big majority do not skip a version, and #46387 lists 3 viable (not even complicated) workarounds that just need to be well documented.

Forcing ourselves to generally support upgrades from two versions back will result in a 1.5 year delay in fully using major nix updates (with beneficial new language features like placeholders) and phasing out old stuff, like deprecated options etc. It also increases the complexity of maintenance ("this cannot be cherry-picked to stable, it uses a placeholder, not allowed in 18.09...") and is likely to generate more bugs.

My impression was that this was the original intention, to make things easier on users.

From where did you get this impression?

How many users do we think this is relevant for?

One of the teams at my company has a fairly large Nix codebase, and they generally do not try to keep up with the 6 month release cycle of NixOS. I try to push them to stay within a year, e.g. the most recent upgrade was from 17.03 to 18.03. But generally I think NixOS's lack of support for things beyond 6 months is pretty bad for large companies. I would advocate for either year long support windows or occasional LTS releases.

From where did you get this impression?

Maybe it was a misunderstanding, but part of the idea to wait so long to up minver.nix was so that the change happened immediately after the 18.09 branch off, not immediately before it. It's not a huge deal either way - I think everyone agrees that we should be switching to 2.0 soon, I just thought we could provide compat in 18.09.

@matthewbauer I see, thanks for explaining. :)

@ElvishJerricco we don't really have the manpower to support releases longer than we currently do. And you should be aware that there generally are no security months after 7 months.

I guess to have an extended support cycle companies would have to start being willing to pay for that at least in some form, otherwise I think it won't be sustainable.

Bummer, but okay.

Mmm 17.09 includes a nixStable2 package. I think if users have to update Nix on their current channel before they update NixOS, that's fine.

I was just trying to upgrade from a really old installer image (nixos-unstable circa 17.03 or 17.09) and I hit an issue where the nixos-18.03 channel did not evaluate without Nix 2.0. So even going to 18.03 required a Nix upgrade. [When I am less tired I'll try to reproduce this and make a proper issue.]

@Ericson2314 I've noted elsewhere that at least going to 18.03 with nixos-rebuild works fine from pretty old NixOSes, because nixos-rebuild takes the Nix from the channel being installed and builds the rest of the system with that.