Conversation
emacs: teach elisp builders the finalAttrs pattern
graphviz: 10.0.1 -> 12.1.0
perl: add cc in addition to makeBinaryWrapper
openblas: 0.3.27 -> 0.3.28
boost{,-build}: fix building with llvm
[staging] iproute2: fix static build again
python312Packages.pikepdf: 9.1.0 -> 9.1.1
For example, when cross compiling to s390-linux.
Fixes e.g. the `sudo` build failure
These utilities will now leave the string undisturbed if it doesn't need to be quoted (because it doesn't have any special characters). This can help generate nicer-looking command lines. This also transitively improves the output of `lib.toGNUCommandLine` which uses `escapeShellArg` internally
openfec: 1.4.2.9 -> 1.4.2.11
buildGoModule: Fix overriding with overlay-style stdenv
krb5 and libkrb5 are two separate derivations that can easily end up in the same closure. They both provide the same shared libraries and some packages end up getting both copies. Since both copies come from the same source, packages often get lucky in this situation and just use whichever library is found first. Sometimes packages are less fortunate and end up trying to load both. This has gone largely unnoticed in Nixpkgs, likely because Kerberos is not widely used outside of enterprise deployments. This situation seems to have arisen out of a need to break a cycle in `fetchurl -> curl -> krb5 -> fetchurl`. The libkrb5 build was able to avoid depending on bison and libedit, making it easier to break the cycle. However, we can break the cycle without resorting to two variants of krb5. Libedit can be removed with configure flags and byacc can be used instead of bison, allowing a much smaller build closure that can easily be resolved when breaking the cycle. This change also adds a "lib" output to krb5 so that packages depending on krb5 can still benefit from a smaller runtime closure if they only need the shared libraries. A future change will include a tree-wide refactor to switch uses of libkrb5 to krb5.
libheif: 1.18.0 -> 1.18.2
It's not very precise; unittestCheckHook doesn't support better?
Member
Author
|
Uh, the |
Member
|
Yeah, sorry about that. There were quite some leaf packages missing. Luckily, the changes were very mechanical. |
Member
Author
|
I wasn't able to fix some cases. IIRC it was those that were using |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Helpful links
https://hydra.nixos.org/job/nixpkgs/staging-next/unstable#tabs-constituents
https://hydra.nixos.org/job/nixos/staging-next-small/tested
https://hydra.nixos.org/jobset/nixpkgs/staging-next
https://hydra.nixos.org/jobset/nixos/staging-next-small
Mass breakages
nothing notable so far