It was a awesome seeing all of you (again), thanks everyone for coming! You made this the greatest Zürich ZHF hackathon ever.

I hope each of you could derive some pleasure from the event and take something away — I sure did. Would love to keep up that spirit in May!

When I upgrade my system from nixos-24.05 to nixos-24.11 I get this:

building Nix...
building the system configuration...
error:
       … while calling the 'head' builtin
         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/attrsets.nix:1:35741:
       … while evaluating the attribute 'value'
         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/modules.nix:1:33591:
       … while evaluating the option `system.build.toplevel':

       … while evaluating definitions from `/nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/system/activation/top-level.nix':

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error:
       Failed assertions:
       - The option definition `sound' in `/etc/nixos/configuration.nix' no longer has any effect; please remove it.
       The option was heavily overloaded and can be removed from most configurations.

Is there any way we can make this a bit more 'user friendly'?

When I upgrade my system from nixos-24.05 to nixos-24.11 I get this:

building Nix...
building the system configuration...
error:
       … while calling the 'head' builtin
         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/attrsets.nix:1:35741:
       … while evaluating the attribute 'value'
         at /nix/var/nix/profiles/per-user/root/channels/nixos/lib/modules.nix:1:33591:
       … while evaluating the option `system.build.toplevel':

       … while evaluating definitions from `/nix/var/nix/profiles/per-user/root/channels/nixos/nixos/modules/system/activation/top-level.nix':

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error:
       Failed assertions:
       - The option definition `sound' in `/etc/nixos/configuration.nix' no longer has any effect; please remove it.
       The option was heavily overloaded and can be removed from most configurations.

Is there any way we can make this a bit more 'user friendly'?
Also, how should I submit a ticket for this and at what location?

It is triggered by this entry in configuration.nix which comes as a default (in a previous install method):

  # Enable sound.
  sound.enable = true;

This is a combination of both nix errors being verbose in the wrong way

And nixos evaluation assertions triggering overly verbose errors.

If only the error message showed up with a reference to the definition, would that be a good behavior?

This is done/possible with some other settings

However not sound apparently

In reply to @koen:procolix.com
I would prefer that NixOS would just ignore the statement and throw a warning that it is depreciated.

In reply to @micmine:matrix.org
Are the pictures that were taken available somewhere?

But still, this is an example of breaking changes when upgrading from a half yearly release to the next

Outlined in the changelog and migration guide too: https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md#sound-options-removal-sec-release-2411-migration-sound

In reply to @elikoga:matrix.org

But still, this is an example of breaking changes when upgrading from a half yearly release to the next

Outlined in the changelog and migration guide too: https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2411.section.md#sound-options-removal-sec-release-2411-migration-sound

I'm saying that in some cases, no better alternive exists. Breaking means breaking sometimes.

I know that if the enable option had an equivalent replacement "mkRenamedOptionModule" could've been used to warn about the rename.

In this case however, the external Api has changed and the courtesy of notifying an upgrading user has been fulfilled. Little can be done except delay the change associated with external api change.

Also "kill [...] with fire" seems a bit heavy handed, it could certainly be spaced out on 2 release cycles with a warning in the first one

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

In reply to @infinisil:matrix.org
I think it's pretty standard to at least warn for a release before failing. Only in rare cases this isn't feasible, but here it is (by just ignoring the option being set). Honestly seems like a bit of an oversight, because it's rare for an option to be just removable like that.