jiebi/CodeConvo huggingface dataset:
Change:
{ lib , fetchFromGitHub <ins> , fetchpatch </ins> # Python bits: , buildPythonPackage , pytest

Discussion:
Steps to reproduce the behavior: in configuration unstable to: Add any other context about the problem here.
It looks like this has already been fixed upstream in There isn't a tagged release containing this fix though (it seems like there was a 4.6.2 but it's gone now: ), so maybe it just needs pulling in as a patch?
cc
Went ahead and pulled it in as a patch: , And opened a PR:
meta: mentioning to enable searches by that term. (I didn't know the FQDN of the package, so I couldn't find this issue).
Thanks for the quick fix! Verified on unstable now.
Change:
<ins> { lib, rustPlatform, fetchFromGitLab }: rustPlatform.buildRustPackage rec { pname = "ristate"; version = "unstable-2021-09-10"; src = fetchFromGitLab { owner = "snakedye"; repo = pname; rev = "34dfd0a0bab5b36df118d8da3956fd938c625b15"; sha256 = "sha256-CH9DZ/7Bhbe6qKg1Nbj1rA9SzIsqVlBJg51XxAh0XnY="; }; cargoSha256 = "sha256-HTfRWvE3m7XZhZDj5bEkrQI3pD6GNiKd2gJtMjRQ8Rw="; meta = with lib; { description = "A river-status client written in Rust"; homepage = "https://gitlab.com/snakedye/ristate"; license = licenses.mit; maintainers = with maintainers; [ kranzes ]; }; } </ins>

Discussion:
Project description Provides status information for river. Useful for bars. Metadata source URL: license: mit platforms: linux
Change:
<ins> { rustPlatform , fetchFromGitHub , pkg-config , openssl , lib , stdenv , testers , libetebase }: rustPlatform.buildRustPackage rec { pname = "libetebase"; version = "0.5.6"; src = fetchFromGitHub { owner = "etesync"; repo = "libetebase"; rev = "v${version}"; hash = "sha256-cXuOKfyMdk+YzDi0G8i44dyBRf4Ez5+AlCKG43BTSSU="; }; cargoHash = "sha256-GUNj5GrY04CXnej3WDKZmW4EeJhoCl2blHSDfEkQKtE="; nativeBuildInputs = [ pkg-config ]; buildInputs = [ openssl ]; postInstall = '' install -d $out/lib/pkgconfig sed s#@prefix@#$out#g etebase.pc.in > $out/lib/pkgconfig/etebase.pc install -Dm644 EtebaseConfig.cmake -t $out/lib/cmake/Etebase install -Dm644 target/etebase.h -t $out/include/etebase ln -s $out/lib/libetebase.so $out/lib/libetebase.so.0 ''; passthru.tests.pkgs-config = testers.testMetaPkgConfig libetebase; meta = with lib; { description = "A C library for Etebase"; homepage = "https://www.etebase.com/"; license = licenses.bsd3; broken = stdenv.isDarwin; maintainers = with maintainers; [ laalsaas ]; pkgConfigModules = [ "etebase" ]; }; } </ins>

Discussion:
Project description EteSync is a "secure, end-to-end encrypted, and privacy respecting sync for your contacts, calendars, tasks and notes." Since GSoC 2020 KDE supports it. automatically detects if it is installed and builds the appropriate modules. Metadata homepage URL: ("build from source" link points to a site that is gone) build instructions: source URL: license: BSD-3-Clause platforms: unix, linux, darwin, ...
Change:
rm -f $out/share/atom/resources/app.asar.unpacked/node_modules/dugite/git/bin/git ln -s ${pkgs.git}/bin/git $out/share/atom/resources/app.asar.unpacked/node_modules/dugite/git/bin/git <ins> rm -f $out/share/atom/resources/app.asar.unpacked/node_modules/dugite/git/libexec/git-core/git ln -s ${pkgs.git}/bin/git $out/share/atom/resources/app.asar.unpacked/node_modules/dugite/git/libexec/git-core/git </ins> find $out/share/atom -name "*.node" -exec patchelf --set-rpath "${atomEnv.libPath}:$out/share/atom" {} ;

Discussion:
I tried to push with the integrated git features but got this error: Folder with git repository some changes, commit and try to push of pushing, you get this error Atom: 1.12.1 system: host os: multi-user?: sandbox: version: nixpkgs:
Got the same issue here.
Still reproducible after 18.03 release. system: host os: multi-user?: sandbox: version: channels(davidak): channels(root): nixpkgs: It was fixed before, but it seems the path has changed.
Change:
<del> { stdenv, fetchurl, pkgconfig, gtk, girara, gettext, docutils }: </del> <ins> { stdenv, fetchurl, pkgconfig, gtk, girara, gettext, docutils, file, makeWrapper }: </ins> stdenv.mkDerivation rec {

Discussion:
i created a fresh for a python repo i use, i forgot a few dependencies the install process fetches them while happyly breaking building wheels i expected to get a hard failure i believe should not use pip to install packages branch in the repo upcoming System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: (run ) Nixpkgs version: (run ) :
you have network access (which you do in a ) then yes, any program can fetch. This is expected and will happen with more programs. should we install packages? Saying that we shouldn't do a certain thing without further argumentation nor alternatives isn't very constructive.
for 1. i would expect no network action possible while building the environment (in order to stay reasonably close to the real env) as for installing python packages, it i believe it should be much saver to have a wheel as a output, and use that to generate a target folder unfortunately im not sure how to prototype such a pip-free builder - there would be a need for a stage1 set of setuptools/wheel packages to bootstrap setuptools/wheel wheels and go with the rest
How would you do that in ? Anyway, that is something to discuss on the Nix tracker, not here. By default we build wheels, and then install the wheels. The wheels can be build in different ways. We could use but we have certain arguments we pass to and I don't know whether accepts those. Building the wheel, and installing the wheel is already separated. We only use for installing the wheel. If would be sufficient we could get rid of . Bootstrapping isn't such a big problem; that's basically just unzipping the wheels as we do already.
(triage) Needs closing? :)
There is no good alternative so closing.
Change:
, openssl , withTTS ? false , speechd <ins> , darwin </ins> }: <ins> let inherit (darwin.apple_sdk.frameworks) CoreAudio AudioUnit AVFoundation AppKit; in </ins> rustPlatform.buildRustPackage rec { pname = "blightmud"; version = "5.3.0";

Discussion:
Steps to reproduce the behavior: blightmud on arm64-darwin (unsupported system) command: full log: <!-- 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]:
I submitted a blightmud issue prior to this one Let me know if there's anything I can do to help
If you'd like to submit patches to add additional OS/arch support I would be willing to try and review, but as mentioned on I won't be able to drive the effort from my end.
Should be working now, could you please test it? or if you don't have checked out:
Hey this worked for me. Thanks for the fix!
Change:
}; }; <del> services.jellyfin.package = mkDefault ( if versionAtLeast config.system.stateVersion "20.09" then pkgs.jellyfin else pkgs.jellyfin_10_5 ); </del> users.users = mkIf (cfg.user == "jellyfin") { jellyfin = { group = cfg.group;

Discussion:
, CVSSv3=6.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc Cc
Change:
dbus-map = callPackage ../tools/misc/dbus-map { }; <ins> deepspeech = callPackage ../misc/deepspeech { }; </ins> dell-530cdn = callPackage ../misc/drivers/dell-530cdn {}; demjson = with python3Packages; toPythonApplication demjson;

Discussion:
Project description DeepSpeech is an open source Speech-To-Text engine, using a model trained by machine learning techniques based on Baidu's Deep Speech research paper. Project DeepSpeech uses Google's TensorFlow to make the implementation easier. Metadata homepage URL: source URL: license: Mozilla Public License platforms: Unsure
I already tried this with a local clone of deepspeech: But I get this error for unknown reasons:
I guess pip is searching for a python package named sox.
That one doesn't seem to be in nixpkgs, is that right?
Doesn't look like it, you might want to package that as well looks like this would need packaged as well
There is .
I marked this as stale due to inactivity. &rarr;
:(
I binary package in , which works fine for my use case (linking to it from Rust). The binary itself works fine as well
Change:
# Run the library tests as they don't have external dependencies doCheck = true; <ins> checkInputs = lib.optionals stdenv.isDarwin [ getconf ]; </ins> checkPhase = '' runHook preCheck # test list repeats suites. Unique them

Discussion:
Describe the bug With the recent update (), the derivations fail during on Darwin. This is due to the test framework using , which seems to be present in the Linux stdenv but is not present in the Darwin stdenv. This can be fixed by adding to the of both the derivation and all derivations. Unfortunately I am not able to submit a PR at this time. To Reproduce Steps to reproduce the behavior: Darwin, run Expected behavior It should build Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
buildPythonPackage rec { pname = "pydantic"; <del> version = "1.8"; </del> <ins> version = "1.8.1"; </ins> disabled = pythonOlder "3.7"; src = fetchFromGitHub { owner = "samuelcolvin"; repo = pname; rev = "v${version}"; <del> sha256 = "sha256-+HfnM/IrFlUyQJdiOYyaJUNenh8dLtd8CUJWSbn6hwQ="; </del> <ins> sha256 = "1zvcmx3927fgx37gdhi8g8igvrkri1v78rn3118p4wssqhgfwa6n"; </ins> }; propagatedBuildInputs = [

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: pythonPackages.pydantic <!-- 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: 1.8 desired version: 1.8.1 <!-- 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:
sha256 = "sha256-5sy8oWVvTmFrRlf4UU4zpw9ml+nXKUNWV3g5Mio8XSw="; }; <ins> # Patch to fix socks4 and socks4a support under glibc's source fortification # (enabled by default since glibc 2.38-0) patches = [ (fetchpatch { url = "https://www.privoxy.org/gitweb/?p=privoxy.git;a=commitdiff_plain;h=19d7684ca10f6c1279568aa19e9a9da2276851f1"; sha256 = "sha256-bCb0RUVrWeGfqZYFHXDEEx+76xiNyVqehtLvk9C1j+4="; }) ]; </ins> hardeningEnable = [ "pie" ]; nativeBuildInputs = [ autoreconfHook w3m man ];

Discussion:
Even with a minimal one-line config, privoxy runs into a buffer overflow on trying to serve a request. This only happens when privoxy is instructed to use a socks4 or socks4a upstream proxy, not with socks5 or socks5t. This is on current nixpkgs-unstable. I confirmed that this bug does not occur with the old commit of nixpkgs, the last time our privoxy build was touched (version-bumped). So the version bump of privoxy it not at fault. Steps to reproduce the behavior: in the background (even if you don't have a socks proxy listening on ) that the privoxy process aborts Privoxy should not segfault, instead it should properly serve the request (or display an error in case upstream proxy servers were not reachable). No maintainers listed.
I'm currently bisecting. My computer is busy compiling glibc, hence definitive results will still take some time. But I'm down to 9 revisions to test (roughly 3 steps). Pinging because all of those remaining 9 revisions pertain to glibc. Update: Found the commit introducing this bug, it's , which bumped glibc from 2.37-39 to 2.38-0. <details<summarygit bisect log</summary</details<details<summarygdb backtrace</summary</summary
Reading through the , I found the following: GNU C Library with FORTIFYSOURCE. The level of fortification can either be provided, or is set to the highest value supported by the compiler. If not explicitly enabled, then fortify source is forcibly disabled so to keep original behavior unchanged. And source fortification. It seems likely to me that this may be an issue in privoxy, which is now caught by the new glibc. Edit: Ah, your backtrace seems to confirm that:
This might be related to . (However, that issue was bisected to )
Thank you, that makes sense! I'm currently believing that the issue is caused by call to strlcpy() in the Privoxy source. But I didn't verify this hypothesis yet and need to run now. Update: That's confirmed. Removing this call gets rid of the fortify-caused abort.

The compiler warning is also interesting: On inspection, the buffer is actually large enough, but this fact is not properly detected. Update: I intend to change into (in ). This convinces gcc that there is enough space for the strlcpy() operation. It should semantically be the same (note that and point to the same location, they just differ in their types). I welcome comments regarding this proposed fix, will then take care of upstream reporting and submitting an interim pull request.
Change:
if [[ -d ${env}/etc ]]; then for i in ${env}/etc/*; do path="/''${i##*/}" <ins> # NOTE: we're binding /etc/fonts from the host so we don't want to # override it with a path from the FHS environment. if [[ $path == '/fonts' ]]; then continue fi </ins> ro_mounts+=(--ro-bind "$i" "/etc$path") done fi

Discussion:
Describe the bug Apps packaged as AppImage don't seem to respect the system's fontconfig and cursor. Additionally, opening URLs is broken as it seems that doesn't work. To Reproduce Steps to reproduce the behavior: AppImage a URL Expected behavior It should open a browser at the given URL. Screenshots Proper cursor "outside" AppImage: ! Default X11 cursor "inside" AppImage: ! Additional context Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
CC: (seems to be the people that did the most significant work here, sorry if you don't have enough context).
BTW, are you using unstable or you're using with backports? Asking this because I had a similar issue with Discord not opening links, and using the proper Discord from instead of using a backport did the trick: .
I'm using unstable. Updated the issue with metadata.
Fixed in . I suppose you are installing stuff globally and hence why you didn't have the issues I did.
I had this problem too, but I thought it was because the difference between and . Reviewing and testing it ASAP.
Was this also fixed? for me (zettlr uses appimage)
Change:
makeWrapper "$oldExe"  "$out${browser.execdir or "/bin"}/${browserName}${nameSuffix}"  <del> --suffix LD_LIBRARY_PATH ':' "$libs"  </del> <ins> --prefix LD_LIBRARY_PATH ':' "$libs"  </ins> --suffix-each GTK_PATH ':' "$gtk_modules"  --prefix PATH ':' "${xdg-utils}/bin"  --suffix PATH ':' "$out${browser.execdir or "/bin"}" 

Discussion:
Describe the bug I use Firefox as a web browser. When I click on links in discord, nothing happens. If I run from the command line there no errors are displayed when clicking on links. I used to see what discord was doing and found the exact call to that is failing. I used that debug information to create a shell script that invokes with the same args and environment variables and ran that directly and saw the following error message: One of the environment variables that I noticed was which is set by . I also noticed that firefox and discord are built against different versions of . Firefox uses the attribute and Discord uses . Discord forks and execs firefox when you click on a link, and the environment variable that is set by the discord wrapper script is inherited by the firefox process which points firefox at a different version of nss than what it is compiled with. As a temporary workaround, I made a local fork of the discord derivation that uses instead of and links are working now. I would have made a PR but that feels like a fragile workaround because discord and firefox should not need to be compiled against the same version of nss. I think the proper fix is to use a different mechanism to point discord at the the paths in so that it is not inherited by child processes, but I'm not quite sure how to do that. To Reproduce Steps to reproduce the behavior: firefox and discord sure that firefox is set as the default browser firefox and discord to click on a link in discord Notify maintainers Metadata Maintainer information:
There's a wrapper to that appends to , shouldn't it prepend instead?
Also, why does Discord fork according to the error message?
By fork, do you mean launch the subprocess? I think that's just what does
Shouldn't it be the wrapped instead?
It does call the wrapper script, wihch appends to so the paths set by 's wrapper are found and used first, hence the issue of failing to start as it needs and is given
Yes I do mean this. I had my goggles on and was thinking in terms of system calls (launching a process involves -ing the current process and -ing the program)
I think you're right about this. I dug through the commit history for that file and it doesn't look like there was any particular reason for using over .

I also noticed that is used in most derivations in this repo, so it's probably a safe bet. I'll make a PR if a contributor can give me a on the approach. The firefox derivation scares me a little bit and I'm not sure what consequences that change might have.
Change:
<del> { lib, stdenv, fetchurl, fetchpatch, cmake, blas, lapack, gfortran, gmm, fltk, libjpeg </del> <ins> { lib, stdenv, fetchurl, cmake, blas, lapack, gfortran, gmm, fltk, libjpeg </ins> , zlib, libGL, libGLU, xorg, opencascade-occt , python ? null, enablePython ? false }:

Discussion:
Package name: gmsh Latest released version: 4.12.2 Current version on the unstable channel: 4.11.1 Current version on the stable/release channel: 4.11.1 Notify maintainers This package has no maintainers. 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:
passthru.updateScript = bundlerUpdateScript "neocities"; meta = with lib; { <del> description = "The Neocities CLI, written in Ruby"; </del> <ins> description = "CLI and library for interacting with the Neocities API"; </ins> homepage = "https://github.com/neocities/neocities-ruby"; license = licenses.mit; <del> maintainers = with maintainers; [ infinidoge ]; </del> mainProgram = "neocities"; <ins> maintainers = with maintainers; [ dawoox ]; platforms = platforms.unix; </ins> }; }

Discussion:
I'm not really sure how it happened, however we have 2 copies of the Neocities CLI: One from , and another from . After formatting the nix files in each, the only differences are: Description Maintainers Platforms ( lists ) Gemfile lock platform/bundled-with version ( is bundled-with , has as a platform and is bundled-with ) is older, while is newer and slightly more complete, as it seems. One should be removed, with the other aliased to it. CC as the maintainer of the other Neocities package.
this happened before, i wonder if there are more cases like this rn
I'll take care of this -- it seems like is out of date so might as well take care of that, too.
Change:
calculix = callPackage ../applications/science/math/calculix {}; <del> calibre-py2 = libsForQt5.callPackage ../applications/misc/calibre { pythonPackages = python2Packages; }; calibre-py3 = libsForQt5.callPackage ../applications/misc/calibre { pythonPackages = python3Packages; }; calibre = calibre-py3; </del> <ins> calibre = libsForQt5.callPackage ../applications/misc/calibre {}; </ins> calligra = libsForQt5.callPackage ../applications/office/calligra { openjpeg = openjpeg_1;

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: calibre <!-- 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: 4.23.0 desired version: 5.6 <!-- 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:
addCheckDesc = desc: elemType: check: types.addCheck elemType check // { description = "${elemType.description} (with check: ${desc})"; }; <del> nonEmptyStr = addCheckDesc "non-empty" types.str (x: x != "" && ! (all (c: c == " " || c == "t") (stringToCharacters x))); </del> <ins> isNonEmpty = s: (builtins.match "[ tn]*" s) == null; nonEmptyStr = addCheckDesc "non-empty" types.str isNonEmpty; </ins> fileSystems' = toposort fsBefore (attrValues config.fileSystems);

Discussion:
Describe the bug A clear and concise description of what the bug is. I have a separate /nix/ ZFS dataset whose mountpoint I declare in my NixOS config. However when I try to boot that system, it mounts the root dataset, tries to read something out of the nix store (before it's mounted) and fails, prompting me to reboot or ignore. works but doesn't. To Reproduce Steps to reproduce the behavior: a separate ZFS dataset for /nix/ to mount it on /nix and /nix/ respectively that /nix gets mounted before anything is read from the nix store while /nix/ isn't Expected behavior A clear and concise description of what you expected to happen. It should behave the same, no matter the trailing slash. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Metadata Please run and paste the result. Maintainer information:
I think this is because of is handled specially, in particular, it is not unmounted. But isn't matched, so it gets unmounted, which breaks everything (because everything lives in ).
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
Change:
kpt = callPackage ../applications/networking/cluster/kpt { }; <del> krita = libsForQt5.callPackage ../applications/graphics/krita { openjpeg = openjpeg_1; }; </del> <ins> krita = libsForQt5.callPackage ../applications/graphics/krita { }; </ins> krusader = libsForQt5.callPackage ../applications/misc/krusader { };

Discussion:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) CVSSv3=5.5 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: . Cc
See also: ,