jiebi/CodeConvo huggingface dataset:
Change:
python-binance = callPackage ../development/python-modules/python-binance { }; <ins> python-dbusmock = callPackage ../development/python-modules/python-dbusmock { }; </ins> python-engineio = callPackage ../development/python-modules/python-engineio { }; python-hosts = callPackage ../development/python-modules/python-hosts { };

Discussion:
As described in , GNOME 3 needs the to handle authenticating Thunderbolt 3 devices. This is not yet packaged for NixOS. I've bolt myself but have thus far been unsuccessful. Start a Gnome 3 session Navigate to Settings → Devices → Thunderbolt Expected Results: A nice GUI as . Actual Results: An error message: ! (Note: The error message is slightly misleading. Thunderbolt 3 is supported and working on my laptop, albeit with authorization disabled, but without GNOME doesn't know that.) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can you share the errors you have encountered when packaging? Perhaps we can point you to solution.
Right now I'm hitting two roadblocks with bolt itself: the man pages fails somewhere inside asciidoc: I'm not sure how to get more information / further work on that. I disable manpage generation (), everything compiles and links just fine but then fails with:
Yeah, meson sometimes gives incredibly useless error messages. The problem is the build trying to install files in and , which it looks up through pkgconfig. Adding these fixes these: We'll also need to knock out as it tries to create a directory in . This fixed the build for me:
You can try to add flag to the asciidoc command in the meson file (I recommend setting to the local checkout of the project in question). As for the second error, Meson only calls when it fails to write to install destination, which means that some is probably wrong.
There ought to be a message Perhaps you can find it in build directory under if you run with .
Woohoo! ! Now I just have to: things up out how to get the systemd unit file linked out how to properly test a patch against this repo request!
We'll have to make module, something like this: Will probably need too.
Change:
<ins> { buildGoModule, lib, fetchFromGitHub, }: buildGoModule rec { pname = "kwok"; version = "0.6.0"; src = fetchFromGitHub { owner = "kubernetes-sigs"; repo = "kwok"; rev = "refs/tags/v${version}"; hash = "sha256-3g8enPxxh2SaxiDgDwJpAfSjv/iRoBRmTnXwDtuMdFA="; }; vendorHash = "sha256-YVGXYN7PgGgBzxhx6piP3NHRAsR1/pCj97UWB21WNMg="; doCheck = false; # docker is need for test meta = { description = "Simulate massive Kubernetes clusters with low resource usage locally without kubelet"; homepage = "https://kwok.sigs.k8s.io"; changelog = "https://github.com/kubernetes-sigs/kwok/releases/tag/v${version}"; platforms = lib.platforms.linux; maintainers = with lib.maintainers; [ bot-wxt1221 ]; }; } </ins>

Discussion:
Project description Kwok Kubernetes without kubelet for simulating massive Kubernetes clusters with low resource usage locally. would be nice to have, working on Kubernetes simulation things Metadata homepage URL: source URL: license: Apache-2.0 platforms: unix
Change:
Accelerate CoreGraphics CoreVideo; }; <ins> gpg-tui = callPackage ../tools/security/gpg-tui { }; </ins> goa = callPackage ../development/tools/goa { }; gohai = callPackage ../tools/system/gohai { };

Discussion:
I have packaged just for testing and it builds and the tests work. But currently I don't see any benefits for myself, using this program. I don't think it is a good idea to be the maintainer of a program that I am not using. So if you want to have this in nixpkgs, you can use my code here: It worked with x86_64 NixOS.
Change:
<ins> { stdenv , lib , fetchurl , makeWrapper , git , coreutils , jdk , gnuplot , graphviz }: stdenv.mkDerivation rec { pname = "maelstrom"; version = "0.2.3"; src = fetchurl { url = "https://github.com/jepsen-io/maelstrom/releases/download/v${version}/maelstrom.tar.bz2"; hash = "sha256-ISS2qma139Jz9eDxLJvULkqDZeu1vyx9ot4uO0LIVho="; }; installPhase = '' runHook preInstall mkdir $out cp -R lib $out/lib # see https://github.com/jepsen-io/maelstrom/blob/b91beef83ee40add17dfe0baf2df272869e144cf/pkg/maelstrom makeWrapper ${jdk}/bin/java $out/bin/maelstrom  --add-flags -Djava.awt.headless=true  --add-flags "-jar $out/lib/maelstrom.jar"  --set PATH ${lib.makeBinPath runtimeDependencies} runHook postInstall ''; nativeBuildInputs = [ makeWrapper ]; runtimeDependencies = [ git coreutils jdk gnuplot graphviz ]; meta = with lib; { description = "Workbench for writing toy implementations of distributed systems"; homepage = "https://github.com/jepsen-io/maelstrom"; changelog = "https://github.com/jepsen-io/maelstrom/releases/tag/${version}"; mainProgram = "maelstrom"; sourceProvenance = [ sourceTypes.binaryBytecode ]; license = licenses.epl10; maintainers = [ maintainers.emilioziniades ]; platforms = platforms.linux ++ platforms.darwin; }; } </ins>

Discussion:
Project description Workbench for writing toy implementations of distributed system <!-- Describe the project a little: --Metadata homepage URL: source URL: license: mit, bsd, gpl2+ , Eclipse Public License 1 platforms: linux and darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ <del> "version": "1.11.3", "desktopSrcHash": "DJqnMEN7KlRIGefMcZCp27xLnPEoSR8Ml5sN5JfqNSM=", "desktopYarnHash": "15wa3ggw1zcc17lfhzig5qw1bpiph7qd6h53qc5nahmfan4jv06a", "webSrcHash": "D95eVWTAvpStOZK0cjP2V8k1ZTnkGLsA0/woVGqDKEI=", "webYarnHash": "1i0djpnn545n83nmm0hm752b66ai1kh3irkfpvw98300c6q1m7fx" </del> <ins> "version": "1.11.4", "desktopSrcHash": "lIyx1gpPkuOGzHTbkHKNiGsVKEkKUIz/8sj/KZ9XK9o=", "desktopYarnHash": "0m0zzq2wbk7h7anjmj586089j2qgsd5cj99rmi2hmsmssq63fmwk", "webSrcHash": "bZ5SKydrQE+qLQEZ5qS7F1RC33nHZneUd8OwrV1H2T4=", "webYarnHash": "1yji94xcigz54bbhvssj2pgncw9fgal7mzw9h9bfwmny0pjh8c4p" </ins> }

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: element-desktop, element-web <!-- 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: 1.11.3 () desired version: 1.11.4 maintainers: Please tag this issue in your PR.
Change:
}; findutils = callPackage ./findutils { <del> bash = bash_2_05; </del> tinycc = tinycc-musl; gnumake = gnumake-musl; gnutar = gnutar-musl;

Discussion:
When built with default Nix options, is 0, meaning auto. The stdenv guesses the "correct" core count: minimal-bootstrap just makes fail. Here the build of for example: <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --
Change:
with stdenv.lib; stdenv.mkDerivation rec { <del> name = "corosync-2.4.3"; </del> <ins> pname = "corosync"; version = "2.4.5"; </ins> src = fetchurl { <del> url = "http://build.clusterlabs.org/corosync/releases/${name}.tar.gz"; sha256 = "15y5la04qn2lh1gabyifygzpa4dx3ndk5yhmaf7azxyjx0if9rxi"; </del> <ins> url = "http://build.clusterlabs.org/corosync/releases/${pname}-${version}.tar.gz"; sha256 = "0pxs18vci9kq3qnqsg5i1h35jrxxiccwbm0mzja3g8j3izdsyvmb"; </ins> }; nativeBuildInputs = [ makeWrapper pkgconfig ];

Discussion:
, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
merged
Need to keep open for 20.09
Merged to 20.09 too. Closing.
Change:
cfgFmt = pkgs.formats.ini { }; <del> # bluez will complain if some of the sections are not found, so just make them # empty (but present in the file) for now </del> defaults = { General.ControllerMode = "dual"; <del> Controller = { }; GATT = { }; </del> Policy.AutoEnable = cfg.powerOnBoot; };

Discussion:
Bluez complains on startup as visible in : Steps to reproduce the behavior: bluez with the error in There should be no error Looks like the group comes from It has been introduced in Apparently, the group has been removed in bluez 5.56: cc Maintainer information:
Change:
<ins> {stdenv, boost, cmake, pkgconfig, nix, ... }: stdenv.mkDerivation rec { name = "nixos-option"; src = ./.; nativeBuildInputs = [ cmake pkgconfig ]; buildInputs = [ boost nix ]; meta = { license = stdenv.lib.licenses.lgpl2Plus; }; } </ins>

Discussion:
We can currently display a NixOS module option type using, for example: . It seems to me that, to maximize usability, should display this string. Also, the should display this information. Perhaps it should be toggleable, though, since options involving submodule types could be quite large. EDIT: Apparently the field is currently for any submodule type. It would be nice to either pretty-print the whole type or output some kind of structured data there. Run . There is no indication of the type of this option other than the default/example values. System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) Sandboxing enabled: (run )
cc
This was fixed in .
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Change:
tree-sitter = callPackage ../development/python-modules/tree-sitter { }; <del> tree-sitter0_21 = callPackage ../development/python-modules/tree-sitter0_21 { }; </del> <ins> tree-sitter_0_21 = callPackage ../development/python-modules/tree-sitter/0_21.nix { }; </ins> tree-sitter-html = callPackage ../development/python-modules/tree-sitter-html { };

Discussion:
Steps to reproduce the behavior: Originally found building Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That's not a build failure, but an evaluation failure. If you want to make not depend on , you need to figure out where does this dependency comes from, and try to remove it. The reason we disabled is documented in the code: Note that although the issue is fixed, we intentionally provide an expression for , so that we can build with it. See also: You can work around this issue by using instead, or try to be creative and make depend on the latest (and not ), by fixing the upstream issue . Good luck!
I'm closing this, as this is an upstream issue. Ideally it would have been possible to declaratively write with Nix why packages are disabled for certain Python implementation, and that would have improved the evaluation failure message you observed. I think I saw discussion about such a feature, but I can't find any links now unfortunately.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
src = fetchurl { name = "VSCode_${version}_${plat}.${archive_fmt}"; <del> url = "https://vscode-update.azurewebsites.net/${version}/${plat}/stable"; </del> <ins> url = "https://update.code.visualstudio.com/${version}/${plat}/stable"; </ins> inherit sha256; };

Discussion:
Describe the bug Vscode fails to install because no longer exists. To Reproduce Steps to reproduce the behavior: Expected behavior Vscode gets downloaded Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(minibill): channels(root): nixpkgs: Maintainer information:
As a stopgap, you could use vscodium, but I'll look into it
Main problem I see is that this also affects stable
Yeah, any fix should be backported as well
Change:
nettle ] ++ lib.optionals stdenv.isDarwin (with darwin.apple_sdk.frameworks; [ Security SystemConfiguration ]); <del> # Sometimes, tests fail on CI (ofborg) & hydra without this </del> checkFlags = [ <del> # doctest for sequoia-ipc fail for some reason "--skip=macros::assert_send_and_sync" "--skip=macros::time_it" </del> <ins> # https://gitlab.com/sequoia-pgp/sequoia-sq/-/issues/297 "--skip=sq_autocrypt_import" </ins> ]; <ins> # Needed for tests to be able to create a ~/.local/share/sequoia directory preCheck = '' export HOME=$(mktemp -d) ''; </ins> env.ASSET_OUT_DIR = "/tmp/"; doCheck = true;

Discussion:
Steps to reproduce the behavior: Observed: Full checkPhase log (copied from Garnix): Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The checkPhase still fails with this PR applied, but it is a different error: Error: While creating /homeless- Caused by: Permission denied (os error 13)
Thanks for the report (I thought I rebuilt it successfully before I opened the PR). Now should be ready now (the failing test is skipped, and an upstream issue was created).
Change:
let pname = "hplip"; <del> version = "3.21.12"; </del> <ins> version = "3.22.6"; </ins> src = fetchurl { url = "mirror://sourceforge/hplip/${pname}-${version}.tar.gz"; <del> sha256 = "sha256-fvRSPvgbztcVFeHIhA72xoxgJjjBWebdmpJpHO7GT5w="; </del> <ins> sha256 = "sha256-J+0NSS/rsLR8ZWI0gg085XOyT/W2Ljv0ssR/goaNa7Q="; </ins> }; plugin = fetchurl { url = "https://developers.hp.com/sites/default/files/${pname}-${version}-plugin.run"; <del> sha256 = "sha256-eyYNhuff8mM4IpRfn/fLBjQJ23JrTdsHBQ/EH7Ug0gw="; </del> <ins> sha256 = "sha256-MSQCPnSXVLrXS1nPIIvlUx0xshbyU0OlpfLOghZMgvs="; </ins> }; hplipState = substituteAll {

Discussion:
The recent fixes to disable in hplip didn't seem to properly work on , making the whole package fail with a cryptic error. Additionally, due to a dependency failure in PyQt5, the package further refuses to build unless it's disabled. Steps to reproduce the behavior: an aarch64-linux user it fail due to PyQt5 failure that PyQt5 support can be disabled it fail again with -related errors hplip works n/a Current unstable as of writing this is . <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --cc as maintainer
cc as PyQt5 maintainer due to dependency failure - should a separate issue be filed for this?
Can reproduce. I ended up moving the print server to a x86-64 machine which was conveniently only a ~meter away from the RPi.
Also got bit by this on a RaspberryPi 4 server upgrade to 22.05. Did a bit of investigation, and came up with an overlay workaround (and hplip upgrade to 3.22.4) using a patch by the Debian crew: The meat of the issue comes down to the HP folks feeling the need to include their non-free x86/-64 'ImageProcessor' in the default build (even when the applicable flag is specified). So the community consensus is hoping that HP will fix/revert this, but until then everyone's just patching it out. Could this patch be to the patch list (and likely update hplip to 3.22.4) ?
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
FONTCONFIG_FILE = "${fontconfig.out}/etc/fonts/fonts.conf"; <del> propagatedBuildInputs = [ cairosvg pyphen cffi cssselect lxml html5lib tinycss pygobject2 ]; </del> <ins> propagatedBuildInputs = [ cairosvg pyphen cffi cssselect lxml html5lib tinycss ]; # 47043a1fd7e50a892b9836466f521df85d597c4.patch can be removed after next release of weasyprint, see: # https://github.com/Kozea/WeasyPrint/issues/1333#issuecomment-818062970 </ins> patches = [ <ins> (fetchpatch { url = "https://github.com/Kozea/WeasyPrint/commit/47043a1fd7e50a892b9836466f521df85d597c44.patch"; sha256 = "0l9z0hrav3bcdajlg3vbzljq0lkw7hlj8ppzrq3v21hbj1il1nsb"; }) </ins> (substituteAll { src = ./library-paths.patch; fontconfig = "${fontconfig.lib}/lib/libfontconfig${stdenv.hostPlatform.extensions.sharedLibrary}";

Discussion:
Describe the bug Seems to be missing/incorrect fonts used during testing. To Reproduce Steps to reproduce the behavior: Expected behavior passed tests, successful build Additional context Attempted to add fonts via the FONTCONFIGFILE variable which did make a few of the font tests pass, but could not figure out how to make the rest pass. Looked at Cairo, but it seems 1.16.0 is exactly what is needed for weasyprint. Maintainer information:
could you please take a look at this?
In the meantime, does anyone have a workaround? I've tried the following, but the tests still run.
I think it's likely we're hitting this: Locally I tried using the branch with the Nix package and while it doesn't fully work yet it's past the point I was at before where it stopped during testing and just uses increasingly more memory.
Tried the linked patch instead and that seems to fix it. I'll get a PR going.
I was able to get it to build by commenting out the line (with a ).
The package builds on master, not sure what your comment is about.
Yeah, realized my comment was too late, now that it has been fixed.
Change:
description = "Infra manages access to infrastructure such as Kubernetes"; homepage = "https://github.com/infrahq/infra"; changelog = "https://github.com/infrahq/infra/raw/v${version}/CHANGELOG.md"; <del> license = licenses.mit; </del> <ins> license = licenses.elastic; </ins> maintainers = with maintainers; [ peterromfeldhk ]; }; }

Discussion:
The "infra" package is nonfree. Steps to reproduce the behavior: The package should only contain free software. The "infrahq/infra" repository uses the infamous nonfree license "Elastic License" since . The nixpkg incorrectly states that it's under MIT license. The package needs to be removed, reverted to the or manually cleansed from nonfree code (via a fork?).
A bit funny that this proprietary software was kept but was completely removed.
Change:
# bazel test runner include references to /bin/bash substituteInPlace tools/build_rules/test_rules.bzl  <del> --replace /bin/bash ${bash}/bin/bash </del> <ins> --replace /bin/bash ${bashWithDefaultShellUtils}/bin/bash </ins> for i in $(find tools/cpp/ -type f) do substituteInPlace $i  <del> --replace /bin/bash ${bash}/bin/bash </del> <ins> --replace /bin/bash ${bashWithDefaultShellUtils}/bin/bash </ins> done # Fixup scripts that generate scripts. Not fixed up by patchShebangs below. substituteInPlace scripts/bootstrap/compile.sh  <del> --replace /bin/bash ${bash}/bin/bash </del> <ins> --replace /bin/bash ${bashWithDefaultShellUtils}/bin/bash </ins> # add nix environment vars to .bazelrc cat >> .bazelrc <<EOF

Discussion:
I'm trying to use from nixpkgs on my laptop and use remote builders (buildbarn). This fails due to patches that are applied in nixpkgs. Vanilla Bazel has a hardcoded fallback path for bash () . This has the downside of not producing a working fallback for (bash from nixpkgs will default initialize as ). The workaround for this is to default initialize the path variables somewhere else. Currently, this is done . This works fine for local execution, since this is where this function is called. However, this function is never called for remote execution (it is a hack to override things for the local execution environment only). So when using Bazel from nixpkgs locally and enabling remote execution, the shell is set to a bash from nixpkgs during the analysis phase but the variable is explicitly left unset by many actions, leading to the PATH in bash being and resulting in errors when executing tools in a script. I think there are two possible solutions: when using remote execution, do not replace the hardcoded (this is probably not a great fix since it only works for FHS executors) instead of replacing with a regular bash from nixpkgs, add a little helper script that adds shell utils to . This way, any shell rule created by bazel has a minimal set of tools. use when turning on remote execution. This has the downside of only working when the remote builder has a shell in that path. See this for a detailed reproducer: Using bazel from nixpkgs should work with remote execution. Using this version of bazel with remote execution is becoming more viable due to <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- [^1]: [^2]:
got reverted, I'll reopen it.
Could we also remove the related patch here -, or is it still needed for some reason ?
To the best of my understanding, it should be sufficient to use a prepared bash (with tools in the PATH) and remove the patch you mentioned. Probably still a good idea to test this in practice!
Change:
buildInputs = [ boost miniupnpc openssl unbound cppzmq zeromq pcsclite readline <ins> libsodium </ins> ] ++ optionals stdenv.isDarwin [ IOKit CoreData PCSC ]; cmakeFlags = [

Discussion:
Monero is hardforking and changing the proof of work. xmr-stak must be upgraded to v2.5.0 before the 18th of Oct (Thu), or it will stop working Thanks
Thanks & .. When can we expect this to land ? Thanks
It should be ready to merge already.
Change:
1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/Makefile b/test/Makefile <del> index 88dbe5b2b4..f0bdedfdf5 100644 </del> <ins> index 88dbe5b2b4..a2a7a55e20 100644 </ins> --- a/test/Makefile +++ b/test/Makefile @@ -28,7 +28,7 @@ default:

Discussion:
This is regarding hydra build failure. Thanks to a matrix user for pointing out the hydra link! Thank you! Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ lib <ins> , stdenv , fetchpatch </ins> , buildGoModule , fetchFromGitHub , nixosTests , libcap <ins> , go </ins> }: let <del> # ncdns source ncdns = fetchFromGitHub { owner = "namecoin"; repo = "ncdns"; rev = "5adda8d4726d389597df432eb2e17eac1677cea2"; sha256 = "sha256-Q/RrUTY4WfrByvQv1eCX29DQNf2vSIR29msmhgS73xk="; }; </del> <ins> # Note: this module is actually the source code of crypto/x509 # taken from the Go stdlib and patcheed. So, it can't simply # be pinned and added to the vendor dir as everything else. x509 = stdenv.mkDerivation rec { pname = "x509-compressed"; version = "0.0.3"; src = fetchFromGitHub { owner = "namecoin"; repo = "x509-compressed"; rev = "v${version}"; hash = "sha256-BmVtClZ3TsUbQrhwREXa42pUOlkBA4a2HVBzl1sdBIo="; }; patches = [ # https://github.com/namecoin/x509-compressed/pull/4 (fetchpatch { url = "https://github.com/namecoin/x509-compressed/commit/b4fb598b.patch"; hash = "sha256-S4Y4B4FH15IyaTJtSb03C8QffnsMXSYc6q1Gka/PVV4="; }) ]; nativeBuildInputs = [ go ]; buildPhase = '' # Put in our own lockfiles cp ${./x509-go.mod} go.mod cp ${./x509-go.sum} go.sum # Generate Go code env HOME=/tmp go generate ./... # Clean up more references to internal modules # (see https://github.com/namecoin/x509-compressed/pull/4) sed -e '/import "internal/d'  -e 's/goos.IsAndroid/0/g' -i x509/*.go ''; </ins> <del> # script to patch the crypto/x509 package x509 = fetchFromGitHub { owner = "namecoin"; repo = "x509-compressed"; rev = "2e30a62a69dac54a977410f283308df232a5d244"; sha256 = "sha256-/Bd1gYjguj8AiKHyiaIKT+Y3R7kq5gLZlJhY9g/xFXk="; # ncdns must be put in a subdirectory for this to work. postFetch = '' cp -r --no-preserve=mode "${ncdns}" "$out/ncdns" </del> <ins> installPhase = '' cp -r . "$out" </ins> ''; };

Discussion:
Steps to reproduce the behavior: ncdns.goModules with or Add any other context about the problem here. <!-- 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]:
The goModules derivation can't be built since go 1.17, see I don't think I can fix it.