Change:
src = fetchurl { url = "mirror://gnome/sources/librsvg/${lib.versions.majorMinor finalAttrs.version}/librsvg-${finalAttrs.version}.tar.xz"; <del> hash = "sha256-Kiwwvqvzz91ApKbb7T+zPmd8ruXY8wR4gkm3Mee+OFI="; </del> <ins> hash = "sha256-18REqSZAa1l5C+DerhluGO0mBZ2lc/oaqeycp2WKVZw="; </ins> }; cargoDeps = rustPlatform.fetchCargoTarball { inherit (finalAttrs) src; name = "librsvg-deps-${finalAttrs.version}"; <del> hash = "sha256-yJf3V2dPwI+RcDH6Lh/AhUgaisdbTnzdAFt+SeNw9NY="; </del> <ins> hash = "sha256-ta+3KkDtqTLGoKknUn89c+3XHzvcZyPFPFpgLH5f5uw="; </ins> # TODO: move this to fetchCargoTarball dontConfigure = true; };

Discussion:
Steps to reproduce the behavior: Build on <details<summary<subNOTE: an earlier version of this report contained misleading info, preserved for posterity within the collapsed content</sub</summary~Unclear to me.~ ~I have only been able to reproduce this error as a dependency of my (flake-based) NixOS system configuration on .~ ~None of these alone result in an error:~ </detailsFull: Excerpt of output (removed unrelated lines): Flake-based configuration for Asahi (Apple Silicon) system tracking () [Update]: After further searching, I found this upstream issue and fix from 4 years ago: am not sure what to do with that, however. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
My build attempt of libpeas2 is attached:
I was greeted with the same issue when I attempted to update alongside my flake setup.
I would like to add that I get an error in the build when trying to build , but not when directly building libpeas (and I also get the same error when trying to rebuild my system) Edit: I cannot build directly. I was building on accident (because the original issue had a command to build ).
That is because depends on . I am currently bisecting it but it goes slow without
I that because the original issue states that they can build without the issue.
Maybe they have cached older version of nixpkgs flake ref.
This comment appears to state that the linked PR is what caused libpeas2 to fail to build:
Weird. It was supposed to have been fixed by , which is in nixos-unstable according to but still does not build for me.
Apologies for the confusing info I provided in the opening description. I do see build failures for both and now: You're right, thanks. Now I know better for next time to verify stuff like this with rather than , which corresponds to the ref of my current NixOS generation. I'll update the description.
Does not build here, nixpkgs @
cc and who last touched the lua stuff
I hoped this regression should be fixed by
yes, that fixes it, thanks! libpeas2 builds when cherry picking and onto nixos-unstable.

For others wishing to track the status of , the PR adding these commits: , it looks as though the changes have been stuck on the branch for a few days. I haven't yet cherry-picked those commits to verify since I expected them to appear in sooner. But I will try to get to verifying a few hours from now. I'm having some trouble following the chain of related PRs. (or anyone else) do you have a better sense of when we might see those changes make it out of ?
Roughly two weeks from now.

Steps to reproduce the behavior: python3.12-django-4.2.11 Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Here is what I see on my side so far : You should wait until nose support the python3.12 interpreter.
This doesn't mention explicitly, but the issue only exists in currently (PR ). On Hydra e.g. These tests now regressed on *-linux, both pythons, django_4 only.
I was looking upstream but it may not be related to this issue then : still I'll mention it, apparently a fork for the nose lib is better maintained upstream and compatible with python3.12. There has been test failures reported as well on Python 3.11 upstream :
Fixed in