whilst it’s great to see some people step up to help, we need a committer on the package, or some sort of looser restrictions on being able to merge version-bump PR’s.
I found it quite disappointing when I saw that the PR to mark the librewolf package as vulnerable was approved and merged so rapidly, but the PR to bump the package version was (and still is) being delayed for no reason, even after multiple comments and approvals.
[…]
The way to solve this would be of course to have a committer on the team. not sure what the steps are to get something like that rolling.
marking the package as vulnerable has also hurt the userbase of the librewolf nix package by a considerable amount. considering that every user who wants to use it now has to build it from source, me (and i am assuming many others) are stuck wondering what to do next. the librewolf-bin package exists, but is also marked vulnerable. to add to that, the librewolf-bin package also has other issues and isn’t actually recommended for use: #518061 (comment)
I don’t know if I personally will have the time to step up but I can at least try get the ball rolling as Librewolf is my browser of choice. It looks like the merge requests mentioned in the comment have finally been approved, but it is making me wonder why has this happened? What blocked those merges for so long even after approvals?
Please note that “committer” means someone with merge access to the nixpkgs repo, not just a regular maintainer (which can be anyone). Your support is certainly welcome if you wish, but if you’re a regular maintainer, that won’t help this specific issue.
Nothing, a committer just needs to notice the PR exists and click the merge button.
Does this mean librewolf will not be cached? I added it to insecure packages and now it needs to be built which has insane hardware requirements due to linker algorithms being stuck in 80s and needing absolute ai-nonsense-level RAM amount to link big projects
EDIT:
Ah, it was marked as insecure and hence all cache was purged. This is pure evil solution. Now even if I pin last nixpkgs commit that I used for currently running Librewolf it does not use any cache and tries to rebuild it anyway (which I can’t do, no free 200gb ram server lying near my laptop and having days to deal with this). Is there any way to bypass this and use currently installed version and update rest of the system? When I make a librewolf overlay it tries to build it anyway This is literally the opposite of making somebody’s nixos secure - one package may invalidate update of more pressing things. I"m so frustrated with this. Isn’t there a curated list with stuff that will shred people’s systems that should receive extra care when such decisions are made? Like kernel, browsers, other crucial components?
My current solution is to keep the flake lock to the version that worked, and don’t upadate it until it’s resolved.
… Which is easy to do as it seems unstable is down for a week now…
So the issue with nobody with proper title being assigned to it is resolved? Not trying to be picky, just trying to decide if port my flake back to Firefox and spend extra time removing unwanted stuff or risk drama with Librewolf
Perhaps this is a valid solution - remove librewolf from flake temporarily, but create a symlink do it to prevent garbage collecting it and manually symlink the binary somewhere in my $PATH?
Yes. However your nixos doesn’t know that because the current state of the packages on unstable is… From the 2026-06-16… IDK for stable, but it seems like the builds are going and the PRs are merged
Thanks @RustyNova016 ! I could not compile this c soup last time I tried - had a VM with 60GB of ram (so much fun to wait a day to get another linker error, that makes AI want to commit suicide when untangling) this is the quiet apocalypse - not AI destroying the world, just reliance on vertical scaling in key components like a linker used at scale only by a select few
Note that this can only happen if you switch to a generation that doesn’t have librewolf, delete all past generations, run a garbage collect, and then attempt to switch back.
In every other scenario you should have a locally cached copy. You might be holding nix wrong, or went out of your way to purge your cache.
Fair point - so I don’t know how and what is removed, I did have a local copy, just could not do system wide update due to build being queued each time. I tried creating an overlay that pointed to nixpkgs commit prior to Librewolf update or exactly the one that was used in my working configuration and each time Librewolf (older version this time, matching the one from pinned nixpkgs) was being queued for build and not downloaded from cache. Hence I thought it was purged completely for some reason I did try only 4 commits before moving to -bin
This is literally the opposite of making somebody’s nixos secure - one package may invalidate update of more pressing things. I"m so frustrated with this. Isn’t there a curated list with stuff that will shred people’s systems that should receive extra care when such decisions are made? Like kernel, browsers, other crucial components?
this is the quiet apocalypse - not AI destroying the world, just reliance on vertical scaling in key components like a linker used at scale only by a select few 