jiebi/CodeConvo huggingface dataset:
Change:
}; }; <del> qtDeps = [ qtbase qtdeclarative qtlocation qtquickcontrols qtquickcontrols2 qtscript qtwebchannel qtwebengine qtimageformats qtsvg qttools qtwayland ]; qtEnv = env "zoom-us-qt-${qtbase.version}" qtDeps; in stdenv.mkDerivation { </del> <ins> in mkDerivation { </ins> name = "zoom-us-${version}"; src = srcs.${stdenv.hostPlatform.system}; <del> nativeBuildInputs = [ autoPatchelfHook makeWrapper ]; </del> <ins> nativeBuildInputs = [ autoPatchelfHook makeWrapper wrapQtAppsHook ]; </ins> buildInputs = [ <del> dbus glib libGL libX11 libXfixes libuuid libxcb qtEnv libjpeg_turbo ] ++ qtDeps; </del> <ins> dbus glib libGL libX11 libXfixes libuuid libxcb libjpeg_turbo qtbase qtdeclarative qtlocation qtquickcontrols qtquickcontrols2 qtscript qtwebchannel qtwebengine qtimageformats qtsvg qttools qtwayland ]; </ins> runtimeDependencies = optional pulseaudioSupport libpulseaudio;

Discussion:
Describe the bug zoom-us appears to be broken. Caused by a change between .... To Reproduce Steps to reproduce the behavior: Expected behavior Success Additional context Logs: Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(root): channels(mbauer): nixpkgs: Maintainer information: /cc
I'll try using the new Qt infrastructure and see how it interacts with binaries, I guess.
Just using doesn't change anything, but removing from allows it to build. I had to replace with as well. Unfortunately, the application doesn't create a window, but the terminal output is normal. Still investigating.
Fix incoming.
Change:
xsos = callPackage ../os-specific/linux/xsos { }; <del> xmcp = callPackage ../tools/x11/xmcp { }; </del> <ins> xmcp = callPackage ../tools/X11/xmcp { }; </ins> zk = callPackage ../applications/office/zk {};

Discussion:
Updating the unstable channel fails on Darwin: this seems to be due to the by-default case-preserving nature of APFS (and HFS+), introduced with this PR: which adds a path which to macOS is the same as the already existing path. Steps to reproduce the behavior: the unstable channel to a macOS machine A new version of the channel is successfully to the machine. Please run and paste the result.
My bad. Should we add a channel blocker label to this to get the PR merged faster?
Change:
webtest ]); <ins> __darwinAllowLocalNetworking = true; </ins> pythonImportsCheck = [ "conan" ];

Discussion:
Steps to reproduce the behavior: the following to create a shell with The revision for nixpkgs is <!-- 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.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
It seems to work just adding to the disabledTestPaths. since you made the change, would you happen to have any insight about it?
Works for me locally but on Hydra.
Not sure, what's going on.
Change:
rtw88 = callPackage ../os-specific/linux/rtw88 { }; rtlwifi_new = rtw88; <ins> rtw89 = callPackage ../os-specific/linux/rtw89 { }; </ins> openafs_1_8 = callPackage ../servers/openafs/1.8/module.nix { }; openafs_1_9 = callPackage ../servers/openafs/1.9/module.nix { }; # Current stable release; don't backport release updates!

Discussion:
Project description The driver supports Realtek 8852AE, which is a wifi card for some new laptops. Without the driver, the wireless interface would be missing for those computers. (My new Lenovo laptop uses this card and I cannot connect to WiFI currently... I'm not entirely sure how to package this) Metadata homepage URL: source URL: license: GPA 2.0 platforms: Linux
Change:
sha256 = "14l0kl17nirc34frcybzg0snknaks23abhdxkmsqg3k9sil5wk9g"; }; <ins> makeFlags = stdenv.lib.optionalString stdenv.isDarwin "CXXFLAGS=-headerpad_max_install_names"; </ins> # FIXME: This fixes dylib references in the dylibs themselves, but # not in the programs in $out/bin. buildInputs = stdenv.lib.optional stdenv.isDarwin fixDarwinDylibNames;

Discussion:
This is very recent breakage, but the build fails with:
This must be due to some other interaction. icu4c hasn't been updated since November.
Change:
let version = "2.35"; <del> patchSuffix = "-163"; </del> <ins> patchSuffix = "-224"; </ins> sha256 = "sha256-USNzL2tnzNMZMF79OZlx1YWSEivMKmUYob0lEN0M9S4="; in

Discussion:
Specifically systems with AVX but without BMI2 Same as this debian bug: They solved it by pulling the latest stable 2.35 patches: ;a=history;f=sysdeps/x86_64;hb=refs/heads/release/2.35/master For NixOS, one workaround is to install a NixOS system to a usb drive with microcode updates enabled, and use that for the installation. This is because for this series of CPUs (Haswell, 3rd/4th gen) the BMI2 instructions are via a microcode update. Rebuilding the iso with this overlay also works, but this is a mass-rebuild: The diff is produced like this: Where corresponds to 2.35-220 and corresponds to 2.35-163 (our previous state).
It was attempted to update glibc to the latest stable patches in , but this led to some issues.
A temporary fix without rebuilds would be via , I suppose. EDIT: or 22.05 release in the meantime, as I expect it shouldn't be affected and it's still supported for a few weeks. Real fix (taking more time, etc.): most likely update glibc to latest 2.35.x and somehow resolve the regression (and possibly others), and then backport to 22.11 as well.
Redoing update as PR for now.
The glibc update is contained in and channels now.
Change:
dontStrip = true; <ins> env = lib.optionalAttrs stdenv.isDarwin { NIX_CFLAGS_COMPILE = "-Wno-implicit-function-declaration"; }; </ins> buildInputs = [ dune-configurator ];

Discussion:
Steps to reproduce the behavior: on x8664-darwin Package is a dependency of . Builds fine on linux and aarch64-darwin, just fails on x86_64-darwin. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
if you submit a patch, I will review it, but I don’t own any Darwin hardware to test…
Pinging to see if anyone can help on this issue as it's outside my area of expertise. Otherwise will mark which depends on this as broken for darwin x86_64. Many thanks!
Can test later, but it looks like there is a workaround for this exact error at
Thanks. I tried that flag earlier, which turns the error into a warning and allows to build (with warnings). But then when I try and build which depends on this I get linker errors,
and were in 11.0. It should use to override the stdenv to use the 11.0 SDK with an 11.0 deployment target. Edit: It uses , so probably something like (untested):
Many thanks, that worked! Much appreciated.

nix shell nixpkgs#docfd Wanted to try out but it failed to build. I noticed the package is not on the . Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hi thanks for the report. I currently have a PR for version 4.0.0, but this same build error occurs there too, so it's unrelated to version. Strangely docfd builds fine on aarch64-darwin. The problem is with x8664-darwin, and specifically with the ocaml dependency which fails to build as your error message shows. I'm going to open an issue for that an ping the maintainer.
Change:
foxitreader = libsForQt512.callPackage ../applications/misc/foxitreader { }; <del> pdfstudio = import ../applications/misc/pdfstudio { program = "pdfstudio"; inherit callPackage fetchurl libgccjit; </del> <ins> pdfstudio2021 = callPackage ../applications/misc/pdfstudio { year = "2021"; </ins> }; <del> pdfstudioviewer = import ../applications/misc/pdfstudio { </del> <ins> pdfstudio2022 = callPackage ../applications/misc/pdfstudio { year = "2022"; }; pdfstudioviewer = callPackage ../applications/misc/pdfstudio { </ins> program = "pdfstudioviewer"; <del> inherit callPackage fetchurl libgccjit; </del> }; aeolus = callPackage ../applications/audio/aeolus { };

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: pdfstudio name: pdfstudioviewer <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 2021.2.0 desired version: 2022.x.x <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Just purchased license for this product but can't use it as it's a 2022 license. Thanks for your help!
Change:
, slurp , grim , jq <ins> , gnugrep </ins> , bash , python3Packages }: let <del> version = "0-unstable-2024-01-20"; </del> <ins> version = "0-unstable-2024-03-19"; </ins> src = fetchFromGitHub { owner = "OctopusET"; repo = "sway-contrib"; <del> rev = "b7825b218e677c65f6849be061b93bd5654991bf"; hash = "sha256-ZTfItJ77mrNSzXFVcj7OV/6zYBElBj+1LcLLHxBFypk="; </del> <ins> rev = "5d33a290e3cac3f0fed38ff950939da28e3ebfd7"; hash = "sha256-2qYxkXowSSzVcpsPO4JoUqaH/VUkOOWu1RKFXp1CXGs="; </ins> }; meta = with lib; {

Discussion:
Steps to reproduce the behavior: add --wait to your command, for instance: no warning on nixos unstable <!-- 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]:
Change:
makeMakerFlags = "POSTGRES_HOME=${postgresql}"; <ins> # tests freeze in a sandbox doCheck = false; </ins> meta = { homepage = http://search.cpan.org/dist/DBD-Pg/; description = "DBI PostgreSQL interface";

Discussion:
nixpkgs rev
I wonder if this is another case of the socket path being too long...
Tests appear to work iff sandboxing is disabled.
Same issue reproduced locally on
If the hydra build failed, how did this get released to the 18.03 stable channel?
It is not a release blocking build. Here are the constituents: I'm more curious how it ever worked. I can't really imagine that it hasn't changed since the sandbox was enabled on Hydra.
I tried some older revisions and it really looks like DBD-Pg tests never worked in a sandbox. The package was last updated 2015. Bumping to current DBD-Pg 3.7.4 doesn't help either - it first results in an error about the socket path being too long, and after patching that the tests freeze at the same point as with 3.5.3. So let's stick to 3.5.3 and just set .
Sounds good to me, will you or shall I?
I'm working on it.
Change:
ANDROID_BINDER_DEVICES = freeform "binder,hwbinder,vndbinder"; # Futex WAIT_MULTIPLE implementation for Wine / Proton Fsync. <del> # Futex2 interface compatible w/ latest Wine / Proton Fsync. </del> FUTEX = yes; <del> FUTEX2 = yes; </del> FUTEX_PI = yes; }; extraMeta = { <del> branch = "5.14-cacule"; </del> <ins> branch = "5.15-tt"; </ins> maintainers = with lib.maintainers; [ fortuneteller2k lovesegfault ]; description = "Built with custom settings and new features built to provide a stable, responsive and smooth desktop experience"; broken = stdenv.isAarch64;

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on github to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: linuxKernel.kernels.linux_xanmod <!-- The current version can be found easily with the same process than above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: 5.14.16 desired version: 5.15.2-xanmod1-tt <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: This package represents xanmod-cacule(xanmod + cacule cpu scheduler), but xanmod-cacule has been replaced by , so this packages should point to it. I also suggest using the correct versioning, so instead of using 5.15.2 we should use 5.15.2-xanmod1-tt considering that 5.15.2-xanmod2-tt could be released. We could also change the name of this package to linux-xanmod-tt and maybe create another package called just linux-xanmod for the default . Please tag this issue in your PR.
Change:
in { version = testers.testVersion { package = mold; }; <ins> } // lib.optionalAttrs stdenv.isLinux { adapter-gcc = helloTest "adapter-gcc" (hello.override (old: { stdenv = useMoldLinker gccStdenv; })); adapter-llvm = helloTest "adapter-llvm" (hello.override (old: { stdenv = useMoldLinker clangStdenv; })); </ins> wrapped = helloTest "wrapped" (hello.overrideAttrs (previousAttrs: { nativeBuildInputs = (previousAttrs.nativeBuildInputs or [ ]) ++ [ mold-wrapped ]; NIX_CFLAGS_LINK = toString (previousAttrs.NIX_CFLAGS_LINK or "") + " -fuse-ld=mold"; })); <del> adapter = helloTest "adapter" (hello.override (old: { stdenv = useMoldLinker old.stdenv; })); </del> }; };

Discussion:
This issue seems to occur after . Any package built using: will fail to build. Minimal example: output: this would also happen if or were used instead of llvm stdenv. before then, running the same command will succeed. Please run and paste the result.
The easiest solution would be to set to , see
Change:
# lowercase alias (for convenience and required for browser extensions) ln -sf $out/bin/JabRef $out/bin/jabref <del> runHook postInstall </del> ''; meta = with lib; {

Discussion:
Regression: File open dialog again results in crash due to missing GSettings schema path. This was previously reported in and fixed in . Steps to reproduce the behavior: on "Open library" icon File open dialog opens. Please run and paste the result.
Change:
done ''; <ins> # Upstream has a pip hack that results in bin/tensorboard being in both tensorflow # and the propagated input tensorflow-tensorboard, which causes environment collisions. # Another possibility would be to have tensorboard only in the buildInputs # See https://github.com/NixOS/nixpkgs/pull/44381 for more information. postInstall = '' rm $out/bin/tensorboard ''; </ins> pythonImportsCheck = [ "tensorflow" "tensorflow.keras"

Discussion:
Describe the bug Trying to build a shell with python 3.7 and tensorflow, yields the following build error: This is similar to , although this issue is for the old tensorflow 1.15.0 version. To Reproduce Steps to reproduce the behavior: the following file: Expected behavior Tensorflow 2.1.0 is installed correctly. Screenshots n / a Additional context n / a Metadata system: host os: multi-user?: sandbox: version: channels(da): channels(root): nixpkgs: Maintainer information:
Change:
{ lib , buildPythonPackage , fetchFromGitHub <del> , fetchpatch </del> , poetry-core , python , pytestCheckHook

Discussion:
<!-- Note that these are hard requirements --<!-- You can use the "Go to file" functionality on GitHub to find the package Then you can go to the history for this package Find the latest "packagename: oldversion -newversion" commit The "newversion" is the current version of the package --- <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- name: <!-- The current version can be found easily with the same process as above for checking the master branch If an open PR is present for the package, take this version as the current one and link to the PR --current version: desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
Change:
, shaderc , vulkan-headers , wayland <ins> , cudaSupport ? config.cudaSupport , cudaPackages ? { } </ins> }: stdenv.mkDerivation (finalAttrs: { pname = "gpt4all"; <del> version = "2.7.5"; </del> <ins> version = "2.8.0"; </ins> src = fetchFromGitHub { fetchSubmodules = true; <del> hash = "sha256-i/T6gk8ICneW624008eiStgYNv5CE8w0Yx8knk57EFw="; </del> <ins> hash = "sha256-aSz37+1K26Xizf4cpV45a2DnSsl959VQok/ppFRk/hs="; </ins> owner = "nomic-ai"; repo = "gpt4all"; rev = "v${finalAttrs.version}";

Discussion:
Package name: gpt4all Latest released version: 2.8.0 <!-- Search your package here: --- Current version on the unstable channel: 2.7.5 Current version on the stable/release channel: N/A <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> { lib, stdenv, fetchFromGitHub, ocamlPackages, why3 }: </del> <ins> { lib, stdenv, fetchFromGitHub, fetchpatch, ocamlPackages, why3 }: </ins> stdenv.mkDerivation rec { pname = "easycrypt";

Discussion:
When using I'd expect to show Z3 and Alt-Ergo. Steps to reproduce the behavior: (make sure is merged or check out my branch) I'd expect and to be listed. The derivation does : It should do instead to overwrite the config completely. Please run and paste the result.
Thanks for the report. Would you like to open a PR with the proposed change?
Change:
config = mkIf (xcfg.enable && cfg.enable) { environment.systemPackages = [ <del> pkgs.e18.efl pkgs.e18.evas pkgs.e18.emotion pkgs.e18.elementary pkgs.e18.enlightenment </del> <ins> pkgs.e18.efl pkgs.e18.evas pkgs.e18.emotion pkgs.e18.elementary e18_enlightenment </ins> pkgs.e18.terminology pkgs.e18.econnman ]; services.xserver.desktopManager.session = [ { name = "E18"; start = '' <del> ${pkgs.e18.enlightenment}/bin/enlightenment_start </del> <ins> ${e18_enlightenment}/bin/enlightenment_start </ins> waitPID=$! ''; }]; <ins> security.setuidPrograms = [ "e18_freqset" ]; </ins> }; }

Discussion:
When starting the enlightenment version 18 desktop manager on my unstable nixos system, I am getting the following errors regarding the module: and It seems should be a setuid program in the configuration. /cc
Yep it should be, will look into it later. Thanks!
Change:
passthru = { inherit tg_owt; <ins> updateScript = ./update.py; </ins> }; meta = {

Discussion:
, CVSSv3=5.3 (nixos-21.05, nixos-unstable) A reordering issue exists in Telegram before 7.8.1 for Android, Telegram before 7.8.3 for iOS, and Telegram Desktop before 2.8.8. An attacker can cause the server to receive messages in a different order than they were sent a client. Scanned versions: nixos-21.05: ; nixos-unstable: . Cc Cc Cc
Change:
environment.systemPackages = [ pkgs.bcache-tools ]; <ins> services.udev.packages = [ pkgs.bcache-tools ]; </ins> boot.initrd.extraUdevRulesCommands = '' cp -v ${pkgs.bcache-tools}/lib/udev/rules.d/*.rules $out/ '';

Discussion:
installs udev rules into the initrd but not into the main system. As a result, symlinks to bcache devices from and are missing. Adding to doesn't quite suffice as a workaround because of a hardcoded reference to . Instead I had to copy the contents of into and replace with . cc
I was thinking of making the rules file from bcache-tools depend on {bash}/bin/sh is replaced with something appropriate when the file is copied for the initrd (like the other replacements are handled). Then we can simply extend the bcache nixos module with " = [ bcache-tools]" and everything should work, I think. CC author of the patch that introduces /bin/sh in the udev rules. Does that sound like a plan?
I created , but it doesn't seem to work. I still have no symlinks to bcache devices under .
Strange. Everything's fine with the workaround I described, and I can't see anything wrong with your patch.
Yep, that sounds like a plan! I commented on your patch. I don't see any problems with your code too -- strange.
Wild guess as to what your problem might be: did you by chance test this with a newly-created bcache volume, without putting a filesystem on it? The UUID and label in the symlink belong to the filesystem, not to the volume itself.
This is a bcache + LVM setup I've had for a while. Ah, that means that the filesystem in my setup is on LVM, not bcache. hardware- points to the UUID of the LVM device: And that UUID points to /dev/dm-0:
I created PR
Okay, that would do it. In my case I'm also running LVM, but I have a LUKS layer (named ) in between. The UUID of the symlink that points to is the one shown by . I do not have any UUID symlink pointing to my device, which is formatted as an LVM physical volume.
Change:
wait_for_server() <del> for domain in domains[:-1]: check_issuer(webserver, f"{server}-{domain}.example.test", "pebble") </del> <ins> for domain in domains: if domain != "wildcard": check_issuer(webserver, f"{server}-{domain}.example.test", "pebble") </ins> for domain in domains: check_connection(client, f"{server}-{domain}.example.test") check_connection(client, f"{server}-{domain}-alias.example.test")

Discussion:
If you have: During evaluation I get this error , pointing to the line Steps to reproduce the behavior: As described above I think this is because here The pairs are made using the , while here: It is trying to use the vhostName. So I think it should be Also, maybe this could be a problem as well, however I am not sure: I would submit a MR, but embarrassingly, I couldn't figure out how to test a patched nixpkgs lib in a flake without having my whole system rebuilt. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Broken by . Fixed by .
Change:
- The `users.users.<name>.passwordFile` has been renamed to `users.users.<name>.hashedPasswordFile` to avoid possible confusions. The option is in fact the file-based version of `hashedPassword`, not `password`, and expects a file containing the {manpage}`crypt(3)` hash of the user password. <ins> - `chromiumBeta` and `chromiumDev` have been removed due to the lack of maintenance in nixpkgs. Consider using `chromium` instead. - `google-chrome-beta` and `google-chrome-dev` have been removed due to the lack of maintenance in nixpkgs. Consider using `google-chrome` instead. </ins> - The `services.ananicy.extraRules` option now has the type of `listOf attrs` instead of `string`. - `buildVimPluginFrom2Nix` has been renamed to `buildVimPlugin`, which now

Discussion:
Package name: google-chrome Latest released version: 116.0.5845.187 Current version on the unstable channel: 116.0.5845.179 Current version on the stable/release channel: 116.0.5845.179 Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. -- Please note a new version of Chrome is now available to address an exploited-in-the-wild zero-day vulnerability in the WebP image parsing code in the Chrome browser. This vulnerability could allow arbitrary code execution when a specially crafted image is viewed. Please update as soon as possible. For more information on the vulnerability, tracked as CVE-2023-4863, refer to this disclosure from Google: Note for maintainers: Please tag this issue in your PR.
I'm seeing on both 23.05 and unstable. Per chromium/google-chrome was one of the first things that was patched.
Those versions are released on both channels but on stable updates for google-chrome-dev and google-chrome-beta are missing