Change:
lib.optionalAttrs allowCustomOverrides ((config.packageOverrides or (super: {})) super); <del> # The complete chain of package set builders, applied from top to bottom </del> <ins> # The complete chain of package set builders, applied from top to bottom. # stdenvOverlays must be last as it brings package forward from the # previous bootstrapping phases which have already been overlayed. </ins> toFix = lib.foldl' (lib.flip lib.extends) (self: {}) ([ stdenvBootstappingAndPlatforms platformCompat

Discussion:
If you do an overrideAttrs in a overlay, it gets applied twice. Here is an example. Say we wanted to overlay gnupatch to pass "--disable-merge" to the configure routine. We would write the following overlay (i.e., put this in ) But look what happens when we evaluate it Adding calls shows that the close passed to get invoked twice even though the overlay itself only gets invoked once. It is almost as if has somehow pulled in the final desired expression (i.e., the already overriden one) and then applied the override to it again (giving it twice applied) despite the fact that it was taken from the prior expression (i.e., ). Note that this isn't a simple case of and being mixed up. Switching them gives an infinite recursion error as expected. Please run and paste the results.
Just noticed my overlay invoked trace above is actually a file loaded trace. Moved it down into the overlay function itself to fix this and we see the overlay is actually being twice. This makes more sense. Perhaps it is as simple as the overlay stack accidentally being duplicated somewhere? I think I was wrong to think it had something to do with as the traces indicate the overlay is being applied twice even without . Cheers! -Tyson
you have any idea what's going on?
I have no idea what might be wrong here. From my point of view the only way this could happen is if the overlay is listed twice, or included twice. Trying locally with an old version of Nixpkgs does not reproduce the issue: But I can reproduce it with a recent master of Nixpkgs: So, I confirm that this is a regression in Nixpkgs, which is not the expected behaviour.
Another data point that, unfortunately, just makes things even more confusing (at least in my mind). Here is a modified version that explicitly counts the number of times things aggregate. Both inside a and outside of in an overlay. So it seems that, while the overlay is indeed evaluated twice, the two evaluations are only aggregated inside of . Very strange indeed.
What old version of nixpkgs do you have that doesn't exhibit this issue? I tried all the way back to 17.03-beta~1836 without find anything (using the option get around the change to without).

Before then I can't get overlays to work at all. With a working commit version it would be pretty trivial to it. Thanks!
Another data point. An insightful one this time I hope. I tried building a attribute up bit by bit in all- to track this down and couldn't replicate the problem. After much head scratching, I finally discovered that this only happens (in my limited testing) with the tools used by . That is, if we do the following override the tools set (the first ones) all give the unexpected while the non- set (the second ones) all give the expected
Another data point. It seems to somehow come from/through the stage. If I comment out this stage in , then I stop seeing the double count from packages.
Okay, I think I may have wrapped my head around this one. The final bootstrap stage (provide by ) provides the following overlay to the overlay (provide by ) which passes the previous stages tools through. The problem with this is the previous stages tools have already had the overlay stack applied to them. Bringing them forward into the next stage results in the all the overlay stack following (which is currently ) being applied to them again. Note that this is actually a general issue for the whole bootstrapping overlay system. Any tools brought forward from the previous stage via the is going to suffer from this and windup with the remainder of the overlay stack applied again to them. Possibly should always be at the end of overlays list in If it is only used to bring packages forward, this could be valid as previous packages will already have the overlays applied to them. I don't know if this is correct, but I'll submit a pull request.