This reverts commit 695027f61c.
We really can't have "nix-env -i nix" *not* upgrade nixUnstable to a
newer nixStable. For instance, it would cause "nix upgrade-nix" to
produce a user environment with collisions.
Among other things, this will allow *2nix tools to output plain data
while still being composable with the traditional
callPackage/.override interfaces.
This is already tracked in upstream issue mumble-voip/mumble#3281 and a
fix has been merged in mumble-voip/mumble@caa187373e.
The patch I'm adding here is using the merged commit
mumble-voip/mumble@ea861fe867 and I've
only added it for the stable release because the patch is already
included in the git version.
@pbogdan also had a similar commit to this
(pbogdan/nixpkgs@8029edea29), but the
patch was applied to both stable and git and thus the git version would
have been broken.
Tested by building mumble and mumble_git and running the mumble NixOS VM
test.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @viric, @jgeerds, @abbradar
Fixes: #33655
The stdenvOverrides overlay is used to bring packages forward during
bootstrapping via stdenv.overrides. These packages have already had
the overlays applied to them in the previous boostrapping stage. If
stdenvOverrides is not last in the overlays stack, all remaining
overlays will windup being applied again to these packages.
closes#34086
Since the bump of beets to version 1.4.6 in e5fab33efd
the tests no longer run successfully because beets 1.4.6 introduces a
breaking API change for the Item.move() method which now instead of just
passing copy=True the operation is now passed using a different
"operation" keyword argument.
Unfortunately the original repository of beets-alternatives is
unmaintained since 3 years and thus there is no upstream fix available
at the moment.
However, there is a fork maintained by @wisp3rwind, which addresses this
problem (wisp3rwind/beets-alternatives@33c6525ed4)
and a bunch of other fixes.
The reason why I'm not using the patch from @wisp3rwind is that it
simply doesn't apply against beets-alternatives 0.8.2, but my patch here
essentially does the same.
Signed-off-by: aszlig <aszlig@nix.build>
Upstream issue: geigerzaehler/beets-alternatives#13
Cc: @Profpatsch
I need some module system types here so I can next fix meta-checks for
derivations. I'd like to use a "proper" record type here, but submodule
types seem overkill so holding off with ad-hoc stuff for now. In
practice, all I need for the next step are the `.check` functions so
this is good, especially as the submodule check function is shallow,
saving full inductive type-checking for a later step.