jiebi/CodeConvo huggingface dataset:
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: install -Dm755 OpenBoardImporter $out/bin/OpenBoardImporter ''; }; <del> in stdenv.mkDerivation rec { </del> <ins> in stdenv.mkDerivation { </ins> pname = "openboard"; version = "unstable-2022-11-28";
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: postPatch = '' substituteInPlace OpenBoard.pro  <del> --replace '/usr/include/quazip5' '${quazip}/include/QuaZip-Qt5-${quazip.version}/quazip'  </del> <ins> --replace '/usr/include/quazip5' '${lib.getDev quazip}/include/QuaZip-Qt5-${quazip.version}/quazip'  </ins> --replace '-lquazip5' '-lquazip1-qt5'  <del> --replace '/usr/include/poppler' '${poppler.dev}/include/poppler' </del> <ins> --replace '/usr/include/poppler' '${lib.getDev poppler}/include/poppler' </ins> ''; nativeBuildInputs = [ qmake copyDesktopItems wrapQtAppsHook ];
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: cp -a ${parts}/* parts/ ''; <del> NIX_CFLAGS_COMPILE = "-I${quazip}/include/QuaZip-Qt${lib.versions.major qtbase.version}-${quazip.version}/quazip"; </del> <ins> NIX_CFLAGS_COMPILE = "-I${lib.getDev quazip}/include/QuaZip-Qt${lib.versions.major qtbase.version}-${quazip.version}/quazip"; </ins> qmakeFlags = [ "phoenix.pro"
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: , libsepol , vulkan-headers , vulkan-loader <del> , valgrind </del> , libthai , libdrm , libdatrie
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: libthai libdrm libdatrie <del> valgrind </del> udev # Text rendering fontconfig
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: -e "/^bindir=/ c bindir=$dev/bin" patchShebangs $out $dev <ins> # QTEST_ASSERT and other macros keeps runtime reference to qtbase.dev substituteInPlace "$dev/include/QtTest/qtestassert.h" --replace "__FILE__" "__BASE_FILE__" </ins> ''; dontStrip = debugSymbols;
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: "bin/qmlscene" "bin/qmltestrunner" ]; <del> NIX_CFLAGS_COMPILE = [ "-fmacro-prefix-map=${qtbase.dev}=qtbase.dev" ]; </del> }
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: qtInputs = [ qtbase qtdeclarative qtsvg ]; propagatedBuildInputs = [ hunspell ]; nativeBuildInputs = [ pkg-config ]; <del> outputs = [ "out" ]; </del> }
Code change:
This means nearly all qt6 packages depend on gdb which is 641M on its own. Why is that the case? I can't imagine needing Valgrind for "production" qt6 builds but I have no knowledge in this domain. cc
valgrind was not in my qt6 draft in valgrind was in but valgrind or gdb dont show up in the closure of <details </summaryto compare, </detailsso ... no problem? edit: <details </summary</details
The inputs are only propagated in the output and that's what other packages use. I only came across this because I found gdb in my system closure. showed <the package-quazip -qtbase -valgrind -gdb why did you add valgrind to qt6's propagatedBuildInputs?
It should have been a build time dependency for qtbase. And as it is only referenced in dev output, it should normally not be referenced in system closures, except for issues like Edit, quazip wasn't fixed by that, let me look into it tomorrow.
... so should not be there &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; /nix/store/y1m61ayisqmp29ckzi0qq4fp640qfl3l-qtbase-6.4.1-dev/include/QtTest/qtestmouse.h &rarr; propagatedBuildInputs &rarr; propagatedBuildInputs also may be relevant: in , are copied to
For the , they should have been in dev output, but and do not have dev output, adding it back should be enough. For , it should be of the same problem as in , maybe we should add that in the hooks of qtbase, or we can fix this ad-hoc.

Related discussion:
text: dontWrapQtApps = true; <ins> outputs = [ "out" "dev" ]; </ins> meta = with lib; { description = "Provides access to ZIP archives from Qt programs"; license = licenses.lgpl21Plus;
Code change:
Steps to reproduce the behavior: sure that the system is set up for cross-compiling (extra-platforms). The following patch fixes the cross-build I am looking for (but it might break other builds, I don't know): Issue seems to be that the configure script of libvpx does not know the target (as a result, we need to force it), which results in a mess. By using instead of , the target is understood and everything works for me. Please run and paste the result.
I'm experiencing this issue as well, I'll test your patch in ExpidusOS and I'll reply back with whether or not it works.
After applying your patch, I wasn't able to build it. I'm going to look into what wants it to be so it could compile.
I was able to successfully cross compile , I'll work on bundling into a PR later.
still an issue, and it seems like the fix for armv7l really is as simple as described in this bug report (i.e. change the target flag from "armv7l-linux-gcc" to "armv7-linux-gcc"). if you get a chance to upstream that patch, i'd be happy to test it for cross aarch64-multiplatform and armv7l-hf-multiplatform.
Done. Fixed by .

Related discussion:
text: else if stdenv.hostPlatform.osxMinVersion == "10.5"  then "9" else "8"; <ins> cpu = /**/ if stdenv.hostPlatform.isArmv7 then "armv7" else if stdenv.hostPlatform.isAarch64 then "arm64" else if stdenv.hostPlatform.isx86_32 then "x86" else stdenv.hostPlatform.parsed.cpu.name; </ins> kernel = # Build system doesn't understand BSD, so pretend to be Linux. /**/ if stdenv.isBSD then "linux" else if stdenv.isDarwin then "darwin${darwinVersion}" else stdenv.hostPlatform.parsed.kernel.name; <ins> isGeneric = /**/ (stdenv.hostPlatform.isPower && stdenv.hostPlatform.isLittleEndian) || stdenv.hostPlatform.parsed.cpu.name == "armv6l"; target = /**/ if (stdenv.isBSD || stdenv.hostPlatform != stdenv.buildPlatform) then (if isGeneric then "generic-gnu" else "${cpu}-${kernel}-gcc") else null; </ins> in assert vp8DecoderSupport || vp8EncoderSupport || vp9DecoderSupport || vp9EncoderSupport;
Code change:
Steps to reproduce the behavior: sure that the system is set up for cross-compiling (extra-platforms). The following patch fixes the cross-build I am looking for (but it might break other builds, I don't know): Issue seems to be that the configure script of libvpx does not know the target (as a result, we need to force it), which results in a mess. By using instead of , the target is understood and everything works for me. Please run and paste the result.
I'm experiencing this issue as well, I'll test your patch in ExpidusOS and I'll reply back with whether or not it works.
After applying your patch, I wasn't able to build it. I'm going to look into what wants it to be so it could compile.
I was able to successfully cross compile , I'll work on bundling into a PR later.
still an issue, and it seems like the fix for armv7l really is as simple as described in this bug report (i.e. change the target flag from "armv7l-linux-gcc" to "armv7-linux-gcc"). if you get a chance to upstream that patch, i'd be happy to test it for cross aarch64-multiplatform and armv7l-hf-multiplatform.
Done. Fixed by .

Related discussion:
text: (enableFeature (experimentalSpatialSvcSupport || experimentalFpMbStatsSupport || experimentalEmulateHardwareSupport) "experimental") <del> ] ++ optionals (stdenv.isBSD || stdenv.hostPlatform != stdenv.buildPlatform) [ "--force-target=${stdenv.hostPlatform.parsed.cpu.name}-${kernel}-gcc" </del> <ins> ] ++ optionals (target != null) [ "--target=${target}" </ins> (lib.optionalString stdenv.hostPlatform.isCygwin "--enable-static-msvcrt") ] # Experimental features ++ optional experimentalSpatialSvcSupport "--enable-spatial-svc"
Code change:
Steps to reproduce the behavior: , set the following: Then navigate to a git repo (e.g. nixpkgs) and call Git logs and a success message Nushell prints the following error: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
I have proposed a fix in

Related discussion:
text: # The SSH agent protocol doesn't have support for changing TTYs; however we # can simulate this with the `exec` feature of openssh (see ssh_config(5)) # that hooks a command to the shell currently running the ssh program. <del> Match host * exec "${cfg.package}/bin/gpg-connect-agent --quiet updatestartuptty /bye >/dev/null 2>&1" </del> <ins> Match host * exec "${pkgs.runtimeShell} -c '${cfg.package}/bin/gpg-connect-agent --quiet updatestartuptty /bye >/dev/null 2>&1'" </ins> ''; environment.extraInit = mkIf cfg.agent.enableSSHSupport ''
Code change:
This issue was described by kvtb at Quoting: Extende the ExecStartPre with something like: Currently the unit depends on , maybe there is something smarter to do.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
might be more suitable?

Related discussion:
text: systemd.services.nitter = { description = "Nitter (An alternative Twitter front-end)"; wantedBy = [ "multi-user.target" ]; <del> after = [ "network.target" ]; </del> <ins> wants = [ "network-online.target" ]; after = [ "network-online.target" ]; </ins> serviceConfig = { DynamicUser = true; StateDirectory = "nitter";
Code change:
I'm trying to install ncdu on darwin, which depends on zig; it has started failing to build in recent nixpkgs on the 22.11 track, though. Steps to reproduce the behavior: zig installs cleanly. <details<summaryoutput of nix log</summary<p</p</details Please run and paste the result.

Related discussion:
text: , zlib }: <ins> let zig_0_10_0 = fetchFromGitHub { owner = "ziglang"; repo = "zig"; rev = "0.10.0"; hash = "sha256-DNs937N7PLQimuM2anya4npYXcj6cyH+dRS7AiOX7tw="; }; in </ins> stdenv.mkDerivation rec { pname = "zig"; version = "0.9.1";
Code change:
I'm trying to install ncdu on darwin, which depends on zig; it has started failing to build in recent nixpkgs on the 22.11 track, though. Steps to reproduce the behavior: zig installs cleanly. <details<summaryoutput of nix log</summary<p</p</details Please run and paste the result.

Related discussion:
text: hash = "sha256-x2c4c9RSrNWGqEngio4ArW7dJjW0gg+8nqBwPcR721k="; }; <del> # Fix index out of bounds reading RPATH (cherry-picked from 0.10-dev) patches = [ ./rpath.patch ]; </del> <ins> patches = [ # Fix index out of bounds reading RPATH (cherry-picked from 0.10-dev) ./rpath.patch # Fix build on macOS 13 (cherry-picked from 0.10-dev) ./ventura.patch ]; # TODO: remove on next upgrade prePatch = '' cp -R ${zig_0_10_0}/lib/libc/include/any-macos.13-any lib/libc/include/any-macos.13-any cp -R ${zig_0_10_0}/lib/libc/include/aarch64-macos.13-none lib/libc/include/aarch64-macos.13-gnu cp -R ${zig_0_10_0}/lib/libc/include/x86_64-macos.13-none lib/libc/include/x86_64-macos.13-gnu cp ${zig_0_10_0}/lib/libc/darwin/libSystem.13.tbd lib/libc/darwin/ ''; </ins> nativeBuildInputs = [ cmake