| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Like with non-ESR releases, Firefox ESR now won't build on AMD EPYC
7401P CPUs. See <https://github.com/NixOS/nixpkgs/issues/84283>.
|
| |
|
|
|
| |
Like Firefox, Thunderbird 78 can't be built with GCC on AMD EPYC 7401P
CPUs. See <https://github.com/NixOS/nixpkgs/issues/84283>.
|
| |
|
|
| |
Patches had to be rebased.
|
| | |
|
| |
|
|
|
|
|
|
| |
'c35bb6bebb98193fdc001e6b8c6b6da3bc791c2f'
git-subtree-dir: overlays/patches/nixpkgs-wayland
git-subtree-mainline: 447d62e0ebe782060c3b6681783d46600b2c9b16
git-subtree-split: c35bb6bebb98193fdc001e6b8c6b6da3bc791c2f
|
| |
|
|
|
| |
I can't get to my certification key because of the pandemic. GnuPG
doesn't have a facility for key transition. So here we are.
|
| | |
|
| | |
|
|
|
Since the nixlib root is the NIX_PATH root, overlays were in the
NIX_PATH as "nixpkgs-overlays". Nixpkgs imports that by default to
look for overlays. This meant that an arbitrary Nixpkgs tree would
end up trying to use the Nixlib overlays, which wouldn't always work.
It would also mean that derivations built from those trees wouldn't
match the ones other people would try to build, which is undesirable
for working on nixpkgs. I think this is unfortunate behaviour for
anybody working on nixpkgs, and nixpkgs probably shouldn't load
overlays from impurely at all by default, but it is what it is.
Since I can't really change what upstream nixpkgs does here, the best
I can do is change the nixpkgs in nixlib. It will now load overlays
from a sibling "overlays" directory. Renaming the "nixpkgs-overlays"
directory at the nixlib root to "overlays" means that it will be
loaded by default _only_ by the nixpkgs it is colocated with. It also
means that it is still accessible in the NIX_PATH as <overlays>, which
is fine and convenient as long as nothing starts looking at that by
default.
|