redis: disable aarch64-linux failing test

[ghost]

Resolves #403628 (comment)

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[vcunat]

This is very similar to #422377
Let me mark at least one as channel blocker, as nixos-unstable is blocked by this, three failed attempts on Hydra already.

[ghost]

I've added the optionalString as suggested.

[vcunat]

nixos-unstable is on a 4 days old commit, so let's not wait long with blockers.

[ghost]

Would you mind explaining/sending a link with information on how a channel gets blocked?
I would like to understand how one (less used lets say) program can block a whole channel which is for both x86_64 and aarch64.

[vcunat]

I believe the best reference is https://wiki.nixos.org/wiki/Channel_branches#Internal_channel_update_process

[vcunat]

Why not hide behind lib.optionalString stdenv.hostPlatform.isAarch64? The test doesn't fail on amd64

And... this time that test fails on x86_64-linux:
https://hydra.nixos.org/build/301760014/nixlog/1/tail

[ghost]

Something doesn't make sense here.
I would understand if aarch64-linux would fail after the redis update if there is something that differs from x86_64-linux, but I did build and ran redis after making the above commit.
How does it fail on x86_64-linux now when it didn't before and how does it fail when locally it works.
Does hydra differ somehow from a normal pc?
Like... I don't understand how this is possible.

Also:
wolfgangwalther said about removing this disabled test in the next release because of some commit
How can one know that the above problem won't happen again by doing so if building locally is not a way to verify it?

[vcunat]

Often the difference is that locally you don't have too much other stuff building at the same time.

[Prince213]

Yeah system speed is not considered for reproducibility. I guess it can fail when the system is under heavy load?

[vcunat]

Even with this the aarch64 build needed a few manual retries:
https://hydra.nixos.org/build/301760015#tabs-buildsteps