jiebi/CodeConvo huggingface dataset:
Code change:
url = "https://github.com/mquinson/po4a/releases/download/v${version}/po4a-${version}.tar.gz"; sha256 = "0eb510a66f59de68cf7a205342036cc9fc08b39334b91f1456421a5f3359e68b"; }; <ins> patches = [ (fetchpatch { # make devdoc output reproducible # https://github.com/mquinson/po4a/pull/387 url = "https://github.com/mquinson/po4a/commit/df7433b58f6570558d44b6aac885c2a8f7862e51.patch"; sha256 = "9MVkYiItR2P3PBCUc4OhEOUHQuLqTWUYtYlZ3L8miC8="; }) ]; </ins> nativeBuildInputs = [ docbook_xsl docbook_xsl_ns ModuleBuild ]; propagatedBuildInputs = lib.optional (!stdenv.hostPlatform.isMusl) TextWrapI18N ++ [ LocaleGettext SGMLSpm UnicodeLineBreak PodParser YAMLTiny ]; # TODO: TermReadKey was temporarily removed from propagatedBuildInputs to unfreeze the build

Related discussion:
text: Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . nix-build '<nixpkgs' -A --check --keep-failed You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: nix-store --read-log $(nix-instantiate '<nixpkgs' -A ) Tested on nixpkgs
PR was merged and made it to nixos-unstable, so this should be fixed
Code change:
systemd = handleTest ./systemd.nix {}; systemd-confinement = handleTest ./systemd-confinement.nix {}; systemd-timesyncd = handleTest ./systemd-timesyncd.nix {}; <ins> systemd-networkd-wireguard = handleTest ./systemd-networkd-wireguard.nix {}; </ins> pdns-recursor = handleTest ./pdns-recursor.nix {}; taskserver = handleTest ./taskserver.nix {}; telegraf = handleTest ./telegraf.nix {};

Related discussion:
text: This configuration: If you poke around in the configuration I linked, you should see that I disable NetworkManager and use a static configuration for my main NIC. I can't think of anything special in my config or with this machine that would affect my usage of Wireguard, but I'm also new to using Wireguard. I'm currently on nixpkgs with a few of my own commits on top of . Please run and paste the results.
It doesn't seem happy when already exists... I have done two things, both of which were necessary, to resolve this: the link manually () sure the path to the private key exists (if not, you get a different failure in the journal, with failing). (It's possible that fixing the private key path and rebooting would have been sufficient). I'm leaving this open for two reasons: user should receive a better error message in both cases. that we're in NixOS, we should assume full control of the interface and just re-configure it, instead of failing in the setup script.
I ran into this issue after trying to debug my wireguard setup. My setup is essentialy identical and I get the same error message. Running the start script that is causing the error results in this output. The offending 2 lines are .
I had to go one step further than deleting the interface. I needed to stop the via then redeploy configuration. But this solved it for me. Nixos should handle this much more gracefully.
I had to remove the routes with etc.
The command is . You can build it in your conf as pre-setup command, but it has the nasty side effect that it possible interferes with other connections.
I am still running into this issue.
Code change:
runHook postInstall ''; <del> passthru.tests = testers.testVersion { package = quickemu; }; </del> <ins> passthru.tests = testers.testVersion { version = "4.9.5"; # required for passing tests, TODO: remove when release bump package = quickemu; }; </ins> meta = { description = "Quickly create and run optimised Windows, macOS and Linux virtual machines";

Related discussion:
text: There is a bug in the latest release of quickemu (present in nixpkgs), that sends invalid flags to qemu and thus doesn't work for MacOS (maybe others too). The fix I was planning to PR was to simply move the src to point to the most current revision. I wasn't 100% sure if that was something that I should do however, given it would set the precedent that we follow revisions for this package instead of the version tag, which may add maintenance burden. Just wanted opinions before I made a PR, would it be acceptable to bump the revision temporarily to avoid this issue? It's niche but its real and could affect users of this package. Steps to reproduce the behavior: Pops open a Qemu window with the appropriate screens. Fails with a strange "macos-ventura/macos- file not found", but it is related to the bugged release. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Don't know of any official policy on this. My opinion: If it's a single commit that fixes the issue, you can add a patch. If it's spread out over multiple commits, use current unstable, but that may introduce other unknown regressions and breaking changes. And in any case we'd go back to the release tag on the next release.
Patching sounds like a good idea, hopefully it is just one commit. Though honestly from personal testing the newest release worked perfectly fine (I tested via an override).
Code change:
sha256 = "020gyl8zv83ag6gbcchmqiyx9rh2jca7j8n52zx1gk4rck7kwc01"; }; <del> sourceRoot = "source/OpenEXR"; </del> outputs = [ "bin" "dev" "out" "doc" ]; <del> # Needed because there are some generated sources. Solution: just run them under QEMU. postPatch = '' for file in b44ExpLogTable dwaLookups do # Ecape for both sh and Automake emu=${lib.escapeShellArg (lib.replaceStrings ["$"] ["$$"] emulator)} before="./$file > $file.h" after="$emu $before" substituteInPlace IlmImf/Makefile.am  --replace "$before" "$after" done # Make sure the patch succeeded [[ $(grep "$emu" IlmImf/Makefile.am | wc -l) = 2 ]] ''; preConfigure = '' patchShebangs ./bootstrap ./bootstrap ''; nativeBuildInputs = [ pkgconfig autoconf automake libtool ]; </del> <ins> nativeBuildInputs = [ cmake libtool ]; </ins> propagatedBuildInputs = [ ilmbase zlib ]; enableParallelBuilding = true; <del> doCheck = false; # fails 1 of 1 tests </del> meta = with stdenv.lib; { description = "A high dynamic-range (HDR) image file format";

Related discussion:
text: Describe the bug build of OpenEXR fails to find -lImath24 To Reproduce Expected behavior Successful build. Screenshots Additional context Add any other context about the problem here. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: Maintainer information:
Something seems to be mangling the library names incorrectly? The ilmbase package contains: Notice the periods.
cc.
I lack the hardware to debug this. any ideas?
Repro'd on 10.14
seems to indicate that autoconf-based builds are only supported on linux - we may want to switch this to cmake. Building outside of nix via cmake is working fine for me.
can you give a try?
I can confirm this still builds on at least.
appears to fix this for me (macos 10.14). Reopen if it's still a problem for you.
Code change:
headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

Related discussion:
text: [x] electron 22 bumped in master (). [x] electron 26 bumped in 23.05 (). [x] electron 25 bumped in 23.05 (). [x] electron 24 bumped in 23.05 (). [x] electron 22 bumped in 23.05 (). [ ] We should figure out what else might be vendoring libwebp. Not sure if there's tooling for this? List of derivations to investigate further and possibly patch: [x] High risk stuff (mail clients, IM clients, web browsers) [x] armcord [x] caprine-bin (, ) [x] discord (, ) [x] Darwin version: / [x] fluffychat () [x] gitter (, ) [x] mailspring [x] mattermost-desktop ( / ) [x] mautrix-whatsapp ( / 23.05 ) [x] microsoft-edge ( / ) [x] mullvad-browser ( / ) [x] palemoon-bin (, ) [x] rocketchat-desktop ( / ) [x] signal-desktop (, ) [x] signal-desktop-beta ( / ) [x] slack ( / ) [x] threema-desktop (embedded electron not used) [x] tor-browser-bundle-bin ( / ) [x] tutanota-desktop ( / ) [ ] Libs that other stuff might depend on [x] flutter [x] libcef ( / ) [x] opencv ( / ) [x] qt5.qtimageformats ( / ) [ ] qtwebengine (darwin only, maybe?) [x] smooth ( / ) [x] darktable () [x] golden-cheetah-bin: ships a vulnerable prebuilt libwebp (cc: [ ] koreader: ships a vulnerable prebuilt libwebp (cc: [x] libreoffice () [ ] localsend: ships a vulnerable prebuilt libwebp (cc: [ ] obs-studio () [ ] rigsofrods-bin (ships a vulnerable prebuilt libwebp (cc: [x] Anything Rust that depends (transitively or not) on libwebp-sys2 < v0.1.8 libwebp-sys2 might silently decide to build its vendored version, if it can't find system libwebp or if the crate feature is enabled.
Code change:
headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

Related discussion:
text: [x] () [x] catppuccin-catwalk () [x] Anything Rust that depends (transitively or not) on libwebp-sys < v0.9.3 Linking against system webp is intentionally not supported: [x] oculante [ ] .NET software that uses SkiaSharp. Upstream has yet to release a fixed version. () [ ] avalonia-ilspy [ ] BeatSaberModManager [ ] denaro [ ] galaxy-buds-client [ ] jellyfin [ ] mission-planner [ ] mqttmultimeter [ ] opentracker [ ] openutau [ ] ryujinx [ ] scarab [ ] wasabiwallet [ ] Go software linking with (, ) - broken down per vulnerable lib [ ] (unmaintained, likely never getting patched - action should be getting upstream to migrate away) [x] hydron ( / ) [x] mautrix-whatsapp () [ ] () [ ] hugo [ ] Godot related derivations: these should be unvendored (capability already exists in the build system). [ ] godot4 [ ] godot3 [ ] godot3-server [ ] godot3-headless [ ] godot3-export-templates Built using Godot [ ] lorien [ ] oh-my-git [ ] Electron apps where we ship upstream binaries instead of using nixpkgs electron Best course of action: upstream should update to electron = 26.2.1, = 25.8.1, = 24.8.3, or = 22.3.24 and tag a new release [ ] atom [ ] hakuneko [ ] hyper [ ] indigenous-desktop [ ] joplin-desktop [ ] keeweb (unmaintained, mark as insecure?) [ ] keybase-gui [ ] insomnia [ ] mullvad-vpn [ ] simplenoteFor derivations that vendor a vulnerable libwebp, priority list of preferred action to take: De-vendor libwebp and use the version from nixpkgs. (Difficult/impossible for binary provenance derivations.) Update to a new version from upstream that has a more recent libwebp patched for the vulnerability (TODO: how to check?) Mark as at some point if upstream can't be convinced to make a new release.
Code change:
headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

Related discussion:
text: List of all software in nixpkgs known to contain libwebp:
is now out
i think one way you could check for vendored webp is with nix-locate, searching for , for example darktable might be vulnerable : possibly also koreader the full output
Thanks, that's indeed useful! I think the most common case though would be bundling the code and linking statically with the lib, which wouldn't necessarily be found by this - but maybe I'm just too pessimistic :) EDIT: the ones you found to the tracking in the issue's first comment so we don't lose track of it.
darktable: links with libwebp, the is an internal plugin and is not a vendored version.
koreader: binary provenance, ships a vulnerable prebuilt libwebp (cc:
localsend: binary provenance, ships a vulnerable prebuilt libwebp (cc:
golden-cheetah-bin: binary provenance, ships a vulnerable prebuilt libwebp (cc:
libreoffice sources file lists a libwebp- (or libwebp- for libreoffice-still)
, vendor libwebp via the rust crate libwebp-sys2
Ugh, and good luck finding all the things that end up transitively depending on that crate I guess. I suggested they file a GHSA so dependabot can go and do its thing, but it might still take a while to trickle down through dependents. Anyway, libwebp-sys2 version 0.1.8 looks like it's fixed.
There's also and I can't seem to find the vendored code by grepping for strings in the binaries. Would need further checking, but I'm tempted to say libreoffice is fine?
The libwebp-sys2 crate also will link against the system libwebp if it is found. I'm currently compiling a list of rust packages that use libwebp-sys2.
But since it transparently falls back to the vendored source, I'm going to assume most Rust programs in nixpkgs haven't bothered declaring libwebp (and pkg-config?) as buildInputs... But at least that might give us a lever to patch without requiring an upstream cargo deps bump?
Code change:
headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

Related discussion:
text: the application has enabled the libwebp-sys2 'static' feature, then it will skip looking for the system one and build its own
Unsure how to deal with the libwebp-sys2 things, which would still be vulnerable for cross-compiling and pkgsStatic. Opened an upstream issue:
Hi! Sorry for just popping in randomly, are there any publicly available workarounds for this issue currently? I'm on , but it seems like firefox nor others have gotten their version bump on that branch.
Not really, and as noted in this issue's description relying on the browser's version number is misleading here (because nixpkgs doesn't use the vendored libwebp, so what matters is the version of the libwebp dependency). If someone wants to write instructions using I'll gladly add those to the issue description for future reference.
On the branch we're only missing a few thousand builds per platform right now, so I'd hope for to update tomorrow.
From the : So looks like this one is fine. I'd remove the vendored download to prevent confusion, but looks like this is automatically generated...
staging-next was merged to master, so users on nixos-unstable should have their browsers patched on the next channel bump.
Fixes for Tor Browser & Mullvad Browser:
Hi! I use the branch specifically in my flake, any ETA on when that branch will get the update pushed?
Depends on how fast stuff ends up rebuilding, I'd expect within 1-2 days at the latest. It's all in automation's hands at this point, unless there's somehow a breakage we didn't notice. You can switch to which already has it (but might require you to do more rebuilds from source), or follow for the status of the fix.
I think I might channel-switch for a bit for this fix, thanks for the help!
Code change:
headers = "1v7ap1v520hhghw358k41aahpnaif54qbg6a9dwgmg1di0qwn735"; }; <del> electron_26-bin = mkElectron "26.1.0" { armv7l-linux = "4a4a6587bddce4554657f40fd9d39645ede03a375a1c42455c9b8d556698e5f5"; aarch64-linux = "1ed0996a06e97f5c23ceb8ae767873915c432c0aca5ffd4b37ab5fb1002d9d65"; x86_64-linux = "de78aed71ce17395675a29dcd20c1370473713eb234143dd0fa3e4c5a39504eb"; x86_64-darwin = "39a336baca218058011f39c4fa9a4275348ec7f411789262799d23c9669060d9"; aarch64-darwin = "f39aafcf480ef581161d3dc0b89a91c556dcaed45927ee0b612368016afe7b89"; headers = "134iqsjg6b80jwywccrhkhlrk6vj12d1nmfqbvlcl0d6cyqw6hys"; </del> <ins> electron_26-bin = mkElectron "26.2.1" { armv7l-linux = "27469331e1b19f732f67e4b3ae01bba527b2744e31efec1ef76748c45fe7f262"; aarch64-linux = "fe634b9095120d5b5d2c389ca016c378d1c3ba4f49b33912f9a6d8eb46f76163"; x86_64-linux = "be4ca43f4dbc82cacb4c48a04f3c4589fd560a80a77dbb9bdf6c81721c0064df"; x86_64-darwin = "007413187793c94cd248f52d3e00e2d95ed73b7a3b2c5a618f22eba7af94cd1a"; aarch64-darwin = "4e095994525a0e97e897aad9c1940c8160ce2c9aaf7b6792f31720abc3e04ee6"; headers = "02z604nzcm8iw29s5lsgjlzwn666h3ikxpdfjg2h0mffm82d0wfk"; </ins> }; }

Related discussion:
text: Additional packages which have a vendored libwebp that I found on my system via the that posted in Matrix: slack obs-studio (via ) openutau (via embedded , also oops this package is mine )
Same method as mentioned by Lily, found: android-studio discord idea-community vial (via ) joplin jetbrains-jdk-jcef (via ) qtimageformats (via )
I looked more into .NET apps that depend on Avalonia and I've also confirmed these vendor libwebp (all via ). I've not confirmed that any of them use the vulnerable version directly, but it seems highly likely they do given a new SkiaSharp release has still not been made since the release of the CVE fix: BeatSaberModManager alttpr-opentracker avalonia-ilspy denaro galaxy-buds-client git-credential-manager jellyfin mission-planner mqttmultimeter ryujinx scarab space-station-14-launcher wasabiwallet
same method as hexa and liliy
currently working on a betterbird update. Not sure about thunderbird and I don't really have the time to check it right now. edit
Also going to add onlyoffice-bin, libsForQt5.qt5.qtimageformats, libsForQt6.qt6.qtimageformats and remarkable{,2}-toolchain to the naughty vendoring list.
If it uses buildMozillaMach it uses our system package.
Got a match for "no memory during frame initialization." in : /nix/store/z613gjk28c3q0ypjsdch9vshdlydc9fm-vscodium-1.82.0./lib/vscode/codium
I've ran a grep on ~200K Nix store paths from a full Hydra evaluation - here are the results: Let's start categorizing that a bit and translating it into trackable tasks :) I've already listed all the SkiaSharp dependents. A few other categories I see: CEF users Vendored Electron users Qt libs Flutter Go binaries (e.g. mautrix-whatsapp, but not sure what package the dep is coming from)
For reference, I believe that all supported channels (6) have updated past the patching (the non-vendored one). This weekend turned out to be a pessimistic estimate.