jiebi/CodeConvo huggingface dataset:
Code change:
<del> { stdenv, buildPythonPackage, fetchFromGitHub, six, hypothesis, mock </del> <ins> { stdenv, buildPythonPackage, fetchFromGitHub, fetchpatch, six, hypothesis, mock </ins> , python-Levenshtein, pytest }: buildPythonPackage rec {

Related discussion:
text: Usage: delta echo lower SELF delta echo lower --self SELF __ HelpUtilsTest.testHelpStringBuiltin _ self = <fire.helputilstest.HelpUtilsTest testMethod=testHelpStringBuiltindef testHelpStringBuiltin(self): helpstring = helputils.HelpString('test'.upper) self.assertIn('Type: builtinfunctionormethod', helpstring) self.assertIn('String form: <built-in method upper of', helpstring) E AssertionError: 'Usage: [VARS ...] [--KWARGS ...]' not found in 'Type: builtinfunctionormethodnString form: <built-in method upper of str object at 0x11028d458nDocstring: Return a copy of the string converted to uppercase.nnUsage: SELFn --self SELF' AssertionError _ InspectUtilsTest.testGetFullArgSpecFromBuiltin _ self = <fire.inspectutilstest.InspectUtilsTest testMethod=testGetFullArgSpecFromBuiltindef testGetFullArgSpecFromBuiltin(self): spec = inspectutils.GetFullArgSpec('test'.upper) E AssertionError: Lists differ: ['self'] != [] E E First list contains 1 additional elements.
Code change:
<del> { stdenv, buildPythonPackage, fetchFromGitHub, six, hypothesis, mock </del> <ins> { stdenv, buildPythonPackage, fetchFromGitHub, fetchpatch, six, hypothesis, mock </ins> , python-Levenshtein, pytest }: buildPythonPackage rec {

Related discussion:
text: E First extra element 0: E 'self' E E - ['self'] E + [] AssertionError =============================== warnings summary =============================== /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- DeprecationWarning: 'U' mode is deprecated self.fromlines = open(fromfile, 'U').readlines() /private/var/folders/8g/qgvf93s1b40dd8nhsvqkm0000gn/T/nix-build-python3.7-fire- DeprecationWarning: 'U' mode is deprecated self.tolines = open(tofile, 'U').readlines() -- Docs: ============== 4 failed, 156 passed, 12 warnings in 1.80 seconds =============== builder for '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-' failed with exit code 1 error: build of '/nix/store/dpcwgrlydrrlbdrnf0mi9hmr0kjvia89-python3.7-fire-' failed nix-shell -p nix-info --run "nix-info -m" system: host os: multi-user?: sandbox: version: channels(abathur): nixpkgs: FWIW, I'm also running bash 5 () as my default shell atm, but I see the same error when I manually run launch a bash 4 () shell to run this in. I haven't updated channel in a bit but I don't see any open/recent issue or PR.
Code change:
cp -R "usr/share" "$out/share" chmod -R g-w "$out" <del> # Wrap the startup command makeBinaryWrapper $out/opt/GoofCord/goofcord $out/bin/goofcord  </del> <ins> # use makeShellWrapper (instead of the makeBinaryWrapper provided by wrapGAppsHook3) for proper shell variable expansion # see https://github.com/NixOS/nixpkgs/issues/172583 makeShellWrapper $out/opt/GoofCord/goofcord $out/bin/goofcord  </ins> "''${gappsWrapperArgs[@]}"  --prefix XDG_DATA_DIRS : "${gtk3}/share/gsettings-schemas/${gtk3.name}/"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=UseOzonePlatform,WaylandWindowDecorations,WebRTCPipeWireCapturer}}" 

Related discussion:
text: ArmCord's wrapper seems unable to launch under Wayland, always chooses to launch under Steps to reproduce the behavior: sure and are properly set: Armcord: . ... 's on XWayland (as shown by ). I expect it to launch with Wayland instead of XWayland. Custom wrapper: Test case: Log output: <!-- 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]:
probably need makeShellWrapper instead of makeBinaryWrapper in the package
Thanks for jumping on a PR will review this evening.
Code change:
postInstall = let includedLibs = [ "base" "contrib" "network" "prelude" ]; name = "${pname}-${version}"; <del> packagePaths = builtins.map (l: "$out/${name}/" + l) includedLibs; </del> <ins> packagePaths = builtins.map (l: "$out/${name}/${l}-${version}") includedLibs; </ins> additionalIdris2Paths = builtins.concatStringsSep ":" packagePaths; in '' # Remove existing idris2 wrapper that sets incorrect LD_LIBRARY_PATH

Related discussion:
text: Describe the bug executing terminates with an error. This didn't happen with idris2 Version 0.3. To Reproduce See above and below. Expected behavior The REPL should successfully start and present its own prompt Additional context Notify maintainers Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Could you try setting ? In particular, they should be set here:
The library paths mismatch.
Hey, your seems to be empty. :O This is what my recent install () looks like:
huh, why does it seems empty, it clearly contains stuff?
Ah sorry, I misread the columns then.
Can you compile and run execs?
suggestion:
when I manually adjust the library paths to include the version, it works:
Run with
Will apply, though I am now concerned about the different behavior in NixOS, so maybe I am getting the libs from somewhere else DX
Code change:
*x-nixos.autoresize*) if [ "$fsType" = ext2 -o "$fsType" = ext3 -o "$fsType" = ext4 ]; then echo "resizing $device..." <ins> e2fsck -fp "$device" </ins> resize2fs "$device" fi ;;

Related discussion:
text: Rebooting a NixOS instance on ec2 does not resize the root volume even though Created one of the amazon ec2 instances: nixos-17.03.885.-x86_64-hvm-ebs Resize the ebs volume associated with the instance using the aws console. Reboot the instance. View to see that nothing has changed view Find this in the error logs: System: (Hummingbird) Nix version: nix-env (Nix) 1.11.11 Nixpkgs version: "17.03.885." Sandboxing enabled: build-use-sandbox = false
Code change:
]; cmakeFlags = [ <del> "-DGLSLANG_INSTALL_DIR=${localGlslang}" "-DSPIRV_HEADERS_INSTALL_DIR=${localSpirvHeaders}" </del> <ins> "-DGLSLANG_INSTALL_DIR=${glslang}" "-DSPIRV_HEADERS_INSTALL_DIR=${spirv-headers}" </ins> "-DROBIN_HOOD_HASHING_INSTALL_DIR=${robin-hood-hashing}" "-DBUILD_LAYER_SUPPORT_FILES=ON" # Hide dev warnings that are useless for packaging

Related discussion:
text: name: All packages in current version: 1.2.189.1 desired version: 1.2.200 maintainers: Please tag this issue in your PR.
Code change:
<del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchFromGitHub , isPy27

Related discussion:
text: Describe the bug Tensorflow binary builds don't work on mac os. (neither do the source build, but that's a separate issue) To Reproduce $ nix-build '<nixpkgs' --show-trace -A python37Packages.tensorflow-bin_2 this derivation will be built: /nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow- building '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-'... Sourcing python-recompile-bytecode- Sourcing python-remove-tests-dir-hook Sourcing python-catch-conflicts- Sourcing python-remove-bin-bytecode- Sourcing wheel setup hook Using wheelUnpackPhase Sourcing pip-install-hook Using pipInstallPhase Sourcing python-imports-check- Using pythonImportsCheckPhase Sourcing python-namespaces-hook unpacking sources Executing wheelUnpackPhase Finished executing wheelUnpackPhase patching sources configuring /private/tmp/nix-build-python3.7-tensorflow- /private/tmp/nix-build-python3.7-tensorflow- Unpacking to: unpacked/tensorflow-2.1.0...OK substitute(): ERROR: file '--replace' does not exist error: --- Error
--------------------------------------------------------------------------- nix-build builder for '/nix/store/cc5p6r864smaf5mm8bqb9dbp6d7jkb3x-python3.7-tensorflow-' failed with exit code 1 host os: multi-user?: sandbox: version: channels(noah): nixpkgs: yaml attribute: module:
Code change:
<del> { lib </del> <ins> { stdenv , lib </ins> , buildPythonPackage , fetchFromGitHub , isPy27

Related discussion:
text: Describe the bug tensorflow-bin_2 wants gast-3.2.0 due to but gast has been updated to 3.3.0 so tensorflow refuses to install: To Reproduce Notify maintainers Metadata Maintainer information:
There are also other dependencies that fail the version checks: scipy==1.4.1 and tensorflow-estimator<2.2.0,=2.1.0rc0.
This compiles i'll test it, any feedback appreciated
Got some issues
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Related .
It looks like fixes this.
Code change:
''; }; <del> # Allow DSA keys for now. (These were deprecated in OpenSSH 7.0.) </del> pubkeyAcceptedKeyTypes = mkOption { type = types.listOf types.str; <del> default = [ "+ssh-dss" ]; </del> <ins> default = []; </ins> example = [ "ssh-ed25519" "ssh-rsa" ]; description = '' Specifies the key types that will be used for public key authentication.

Related discussion:
text: ssh-dss was deprecated in 2015. Server support was removed in 17.03. It might be time to remove them client-side, and also from examples.
cc me as openssh maintainer to look at this later
Probably fixed by update
This is still being set through the NixOS option default.
Code change:
# https://docs.nvidia.com/dgx/pdf/dgx-os-5-user-guide.pdf "char-nvidiactl" "char-nvidia-caps" <ins> "char-nvidia-frontend" </ins> "char-nvidia-uvm" # ROCm "char-drm"

Related discussion:
text: this commit makes my NVIDIA GeForce RTX 3090 no longer visible to ollama: needs to be revisited, or add optional flag to disable hardening (which i don't really need since I dont expose ollama over internet). when running through systemd: when running :
Can you check , and try adding these strings, prefixed with to ? For me on NixOS 24.05 they show and the module currently allows the following device types:
Just upgraded to the unstable module and package and things are still looking fine. The only nvidia related config I have is
, will try later when I get back home. Not sure if related but I'm on nvidia as the newer versions are broken in one way or another (wayland/performance regressions/pytorch issues).
You can also try nuking the DevicePolicy altogether if the suggestions above do not work: = { DeviceAllow = lib.mkForce [ ]; DevicePolicy = lib.mkForce "auto"; };
was the missing piece: +
--------+ |-----------------------------------------+----------------------+----------------------+ +-----------------------------------------+----------------------+----------------------+
thanks for your support!
Feel free to send a PR to add it to the module. Thanks for looking into this!
some additional findings, nvidia device group names are definitely driver version dependent, this is what I get on 555 ( is gone):
Code change:
<del> { lib, pkgs, erlang }: </del> <ins> { lib, __splicedPackages, erlang }: </ins> let <ins> pkgs = __splicedPackages; </ins> inherit (lib) makeExtensible; lib' = pkgs.callPackage ./lib.nix { };

Related discussion:
text: Describe the bug I need to list the out paths of cross compiled packages beforehand which causes an eval error. To Reproduce Steps to reproduce the behavior: Expected behavior List all out paths like `. Additional context I need this feature for nixpkgs-review when cross compiling. 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(user): nixpkgs: Maintainer information:
I think its because of the lack of splicing for perl-packages. Note however, that when that is fixed, other package sets will fail with the same issue. cc
Probably multiple issues. Have seen that problem with building xwayland for aarch64 too. Removing makeWrapper helps but probably breaks it :(. But the deps don't cross-build anyway so never got that far for now. Was thinking about opening an issue but got caught up trying to find the issue -- to no avail. Not currently at my machine, might post it later.
I marked this as stale due to inactivity. &rarr;
still important to me
Fix in
Code change:
, stdenv , fetchFromGitHub , rocmUpdateScript <ins> , symlinkJoin , substituteAll </ins> , cmake , clang , clr <ins> , rocm-core </ins> , rocm-thunk <ins> , rocm-device-libs </ins> , roctracer <ins> , rocdbgapi </ins> , rocm-smi , hsa-amd-aqlprofile-bin , numactl

Related discussion:
text: When trying to use rocprofv2: This might have something to do with some predefined paths in Steps to reproduce the behavior: an executable with hipcc it with rocprofv2 <!-- 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.
I need to do some work with . need to make a patch that strips. I need to fix itself. I wonder if it's because I'm stripping out the test directories? Also yes, it looks like you're right. You can fix that by prepending too, so I'm not entirely sure it'll work. Try setting `. You may just be able to run it from that as well.
I don't think that removing hsa-amd-aqlprofile-bin is a good idea, because without it, it loses performance counters support. I think there should at least be a rocprof derivation with aqlprofile.
My bad, I forgot to add that the patch is optional.
Right. Could you tell me your test environment and the source of the hip executable (or just some stub) so I can replicate this? I've never actually used rocprofiler.
You can try this, it just prints 10 numbers, it can be compiled with hipcc without any flag. I am using a radeon rx6600m(gfx1032).
see
Code change:
license = licenses.unfreeRedistributable; maintainers = with maintainers; [ MP2E ]; platforms = platforms.linux; <ins> broken = kernel.kernelOlder "3.2.0"; </ins> }; }

Related discussion:
text: I'm trying to use the mwprocapture nixos module (which uses the mwprocapture kernel package) on 20.09 (linuxPackageslatest), and I get the following: Is this known and/or already fixed somewhere? (Also, is it safe to use it anyways?) I'd love to try and fix it further myself, but I don't know how to splice in a local/development nix file into my for development purposes :sweatsmile: (also CC
Looks like upgrading the package version resolved things. Will create a PR soon.
Thanks for the heads up.
Code change:
forgejo = handleTest ./forgejo.nix { }; freenet = handleTest ./freenet.nix {}; freeswitch = handleTest ./freeswitch.nix {}; <ins> freetube = discoverTests (import ./freetube.nix); </ins> freshrss-sqlite = handleTest ./freshrss-sqlite.nix {}; freshrss-pgsql = handleTest ./freshrss-pgsql.nix {}; frigate = handleTest ./frigate.nix {};

Related discussion:
text: Steps to reproduce the behavior: system configuration with Freetube in it. See and for the exact same issue with Morgen. Electron version lock seems to have been introduced with . Upstream seems to be at Electron 27: . and
Maybe we could add the patches from It looks like they were waiting for a nixos user to test it and eventually gave up on us.
are you able to test ?
Looks good as far as I can tell.
fails on this branch, for whatever reason.
Code change:
"-DMZ_OPENSSL=ON" "-DMZ_BUILD_TESTS=${if finalAttrs.doCheck then "ON" else "OFF"}" "-DMZ_BUILD_UNIT_TESTS=${if finalAttrs.doCheck then "ON" else "OFF"}" <ins> "-DMZ_LIB_SUFFIX='-ng'" </ins> ] ++ lib.optionals stdenv.isDarwin [ # missing header file "-DMZ_LIBCOMP=OFF"

Related discussion:
text: branch to nixos-unstable to your with
Bisect has identified (specifically ) as the source of this failure in nixpkgs, cc See also upstream issue
If you're using a flake, this is how I was able to mitigate this until it's fixed. I rolled back the changes from in a branch on my fork, and used it as an overlay for the affected packages like this: This is how you would add them to your overlay: Ofc, depending on how you do stuff, you'll have to fiddle with it a bit to get it to work. I found this helpful:
The fix is now on the nixos-unstable branch, but I still cannot build my system after updating, with the same build failure for opencolorio. Is this expected?
Probably not, since and both build on Hydra.
Oh thank you, this is very bizarre. I will ask on the forum what's going on
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Code change:
homepage = "https://github.com/electron/electron"; license = licenses.mit; maintainers = with maintainers; [ travisbhartwell manveru prusnak ]; <del> platforms = [ "x86_64-darwin" "x86_64-linux" "i686-linux" "armv7l-linux" "aarch64-linux" ] ++ optionals (versionAtLeast version "11.0.0") [ "aarch64-darwin" ]; </del> <ins> platforms = [ "x86_64-darwin" "x86_64-linux" "armv7l-linux" "aarch64-linux" ] ++ optionals (versionAtLeast version "11.0.0") [ "aarch64-darwin" ] ++ optionals (versionOlder version "19.0.0") [ "i686-linux" ]; </ins> sourceProvenance = with sourceTypes; [ binaryNativeCode ]; knownVulnerabilities = optional (versionOlder version "15.0.0") "Electron version ${version} is EOL"; };

Related discussion:
text: Element v1.11.0 updated to Electron 19, so we need this packaged in Nixpkgs: <!-- 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: 18.1.0 desired version: 19.0.7 <!-- 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.
When I run the script tries to download which does not exist. Do you know where to get the electron headers?
PR that brings electron19 but does not provide electron19 headers:
I believe that states that they migrated storage. So, I think the new url would be
Great find, thanks! Updated PR to include this change and electron_19 now provides the headers.
electrum_19 to master via - feel free to update your package
Code change:
// Insist on using IPC for communicating with Tor // <del> // Defaults to creating $TBB_HOME/TorBrowser/Data/Tor/{socks,control}.socket </del> <ins> // Defaults to creating $XDG_RUNTIME_DIR/Tor/{socks,control}.socket </ins> lockPref("extensions.torlauncher.control_port_use_ipc", true); lockPref("extensions.torlauncher.socks_port_use_ipc", true);

Related discussion:
text: When you try to connect to the Tor network using the Tor browser you get the error message ! When you try to visit a website after being shown the big red error message your get the error message ! This problem appeared between one and two weeks ago. ; can't find an existing Nixpkgs issue. Steps to reproduce the behavior: the Tor browser from Nixpkgs the Tor browser on error message to go to a website When clicking on the browser should connect to the Tor network and be able to browse. The . browsers says that it can detect my internet connection. ! Tor logs doesn't seem to indicate any problems (from what I can interpret) I live in Sweden and this issue has appeared both when I've connected to the internet using my home connection (Sunet) and when I've connected over a VPN. I.e. no fuckery by an oppressive government. The timeline match up-ish with when would have become available in the binary caches. Unsure if the error appeared before or after updating around that time. After checking the original PR I see that this problem was noticed, but a workaround was applied. Doesn't seem to work for me :-/ The value is for me. I'm using root on tmpfs, and nothing under is persistently saved between boots. ! <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- and because you seem to have actually researched the problem. The system is fully up-to-date as of 2023-03-05 22:15 CEST.
The red error message indicates that Tor cannot find the tor socket. Everything else is bound to not work unless it goes over the normal internet. Please see and for the underlying problem and please check if the firefox setting points to the right socket file.
I tested to set to , but that didn't help.
Setting to also doesn't work.
Just to avoid ambiguities, did you set to (with file name part)? TBB is still working fine for me with the workaround. Likewise for me, is a tmpfs. Have you modified (and forgotten about it) your torrc, e.g. to use a different control port/mechanism? What is your XDGSESSIONTYPE?
Code change:
// Insist on using IPC for communicating with Tor // <del> // Defaults to creating $TBB_HOME/TorBrowser/Data/Tor/{socks,control}.socket </del> <ins> // Defaults to creating $XDG_RUNTIME_DIR/Tor/{socks,control}.socket </ins> lockPref("extensions.torlauncher.control_port_use_ipc", true); lockPref("extensions.torlauncher.socks_port_use_ipc", true);

Related discussion:
text: The person on uses wayland (with sway). I currently still use x11 (with i3) and haven't tested it with wayland.
That did it! I missed that you should specify the file in the path. I'm using AwesomeWM.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
The person on had the same problem and the same solution :-)
Why did you close this issue You can't seriously think that this temporary workaround is an acceptable permanent solution to this problem? While we still don't have a permanent solution, it should be as easy as possible for users to find information about this workaround. By closing this issue we signal to people that this problem has been solved. And people currently experiencing this problem on a fully up-to-date system will probably not think about looking into closed issues, because the issue is still there.
I am also experiencing this issue. The fix worked for me.
Confirmed. The issue is still present. Default installed value of is 127.0.0.1. Changing it to resolves the problem.
This issue only started happening on my machine after deleting today.
Still an issue. I'm using TBB with firejail and I have to apply the workaround at every restart. TBB creates the folder but not a profile inside (this wouldn't be a problem for me if connection works out of the box). about:config - = tor-browser-bundle-bin 12.0.5 firejail-0.9.72 nixos-unstable
By default, the service runs on port 9050 and the control port on 9051. This is configured in the torrc file: Your firewall may be blocking some of these ports bound by default to localhost which normally point to 127.0.0.1
The PR for Tor Browser 13 removes the current workaround again, because it seems the issue was fixed upstream: I would be grateful if some of you could give this a try and report if it's still working (or working again).
Code change:
cde-gtk-theme = throw "cde-gtk-theme has been removed from nixpkgs as it shipped with python2 scripts that didn't work anymore"; # Added 2022-01-12 cgmanager = throw "cgmanager was deprecated by lxc and therefore removed from nixpkgs"; # Added 2020-06-05 checkbashism = throw "'checkbashism' has been renamed to/replaced by 'checkbashisms'"; # Converted to throw 2022-02-22 <ins> chefdk = throw "chefdk has been removed due to being deprecated upstream by Chef Workstation"; # Added 2023-03-22 </ins> chrome-gnome-shell = gnome-browser-connector; # Added 2022-07-27 chronos = throw "chronos has been removed from nixpkgs, as it was unmaintained"; # Added 2020-08-15 chunkwm = throw "chunkwm has been removed: abandoned by upstream"; # Added 2022-01-07

Related discussion:
text: ChefDK is deprecated and no longer maintained by Chef. This package is currently maintained by and I believe ChefDK should be dropped and replaced by Chef Workstation (see issue ). This has been deprecated since 2021.