jiebi/CodeConvo huggingface dataset:
Change:
sha256 = "1vik7s3q5hvazvgw4jm4b90qlk6zcry0s314xw1liarspkd721g3"; }; <ins> patches = [ (fetchpatch { name = "search-xdg-data-dirs.patch"; url = https://github.com/zsh-users/zsh/commit/624219e0e4cbfdfb286e707bd2853f2d7b6a4a7d.patch; sha256 = "0i0g7dc0px57vpklm1f4w20vyc92nv15y09r5clvib2kjkxjy2cf"; excludes = [ "ChangeLog" ]; }) ]; </ins> buildInputs = [ ncurses pcre ]; configureFlags = [

Discussion:
type "setxkbmap" then try to trigger completion with <tabPlease run and paste the results. system: host os: multi-user?: sandbox: version: nixpkgs:
I can reproduce it on with ZSH 5.6 (and inside which shouldn't be relevant). I just had a short look through the commit log of and the code is quit old, did it work before for you? (I'm just using in some personal shell scripts and quite rarely directly, so I can't tell if the completionactually worked). However the code of the completion in my seems quite broken for NixOS as it tries to search directories, a behavior that should be patched accordingly. I can try to fix it (didn't find further related issues ATM, let's see)...
I just managed to get it working by adding to the hook of the ZSH package locally. I'm not sure though if it's the best solution. Let me think if there's something better to do, otherwise I'd file a patch :)
would you mind having a look at this patch: Will file it tomorrow, but I'm not sure, why not sure if there's a better way (don't like to manually specify in the derivation).
yep it seems to have fixed it :)
Change:
libmtp liboggz libopus <del> libplacebo </del> <ins> libplacebo_5 </ins> libpulseaudio libraw1394 librsvg

Discussion:
Package name: Latest released version: <!-- Search your package here: --- Current version on the unstable channel: Current version on the stable/release channel: <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR.
Done here:
Change:
rpi-gpio = callPackage ../development/python-modules/rpi-gpio { }; <del> rpi-gpio2 = callPackage ../development/python-modules/rpi-gpio2 { }; </del> rplcd = callPackage ../development/python-modules/rplcd { }; rply = callPackage ../development/python-modules/rply { };

Discussion:
The version of rpi-gpio2 on nixos-unstable (as of ) appears to be incompatible with the version of gpiod at the same point Load the module successfully /cc
I wonder if we should keep/re-introduce a gpiod 1.x to nixpkgs until rpi-gpio2 supports gpiod 2.x?
I have since updated the component I was using rpi-gpio2 with to use libgpiod directly (). Should we mark this component broken in nixpkgs, or perhaps just remove it entirely? It doesn't appear to be used anywhere within nixpkgs. /cc
I got this error today as well, so this issue is still relevant. What is the simplest way to toggle a GPIO pin on NixOS as of today, then?
But I guess I could attempt the trivial fix to change out to in the package definition. That should be the correct fix right?
Change:
src = fetchFromGitHub { owner = "danielfoehrKn"; <del> repo = pname; </del> <ins> repo = "kubeswitch"; </ins> rev = version; <del> sha256 = "sha256-zf7o41YYAppRge0EMXgIN8rI5Kco4/n7BJ90b/X6L1M="; </del> <ins> hash = "sha256-zf7o41YYAppRge0EMXgIN8rI5Kco4/n7BJ90b/X6L1M="; </ins> }; vendorHash = null;

Discussion:
Kubeswitch requires both the binary and a script Steps to reproduce the behavior: kubeswitch to use Kubeconfig is set as intended only adds the binary, not the script itself. On the other hand, I'm not using nix directly but via fleek.
Hey happy first issue! About the kubeswitch, indeed, I did make this mistake as I am using it on my work machine which is not NixOS and I had done the standard installation in the past, so I got the binary from Nix, but not the script. Honestly, I need time and a little bit of searching on how to handle scripts, as I have only messed with Go or Python packages (which have a nice interface, BTW).
This will help fix it.
I did not test, but thanks. are you willing to do fix it?
Hi, sorry I want to but do not have much time recently.
Change:
LIBRARY_PATH = "${stdenv.cc.libc}/lib"; buildInputs = [ gnat zlib ] ++ lib.optional (backend == "llvm") [ llvm ]; <ins> propagatedBuildInputs = lib.optionals (backend == "llvm") [ zlib ]; </ins> preConfigure = '' # If llvm 7.0 works, 7.x releases should work too.

Discussion:
Describe the bug To Reproduce -env -i ghdl-llvm # or nix run ... -a Expected behavior ghdl compiles and runs the code Additional context uses LLVM as a backend to compile VHDL to a simulator executable for RTL simulation. It finally links its outputs using (via a call to gcc). The problem is, that in this linking step it also wants to link , which the linker can not find. However, in a everything works as intended. Even a and appending to NIX_LDPATH suffices. I tried various (combinations) of and friends and also , but never got this to work. I suspect that there is something in the setup hook of the nix-shell, but inspecting and comparing s didn't get me any further. Maybe someone could look into this or introduce me to the dark magic of and packaging compilers. (Looking at other compiler's .nix files also was a dead end for me.)
I marked this as stale due to inactivity. &rarr;
Change:
{ options.services.snapper = { <ins> snapshotRootOnBoot = mkOption { type = types.bool; default = false; description = '' Whether to snapshot root on boot ''; }; </ins> snapshotInterval = mkOption { type = types.str; default = "hourly";

Discussion:
Snapper stops to take snapshots after a system update and reboot. snapper in autoUpgrade and autoUpgrade.allowReboot in for system upgrade and reboot. .service succeds, but snapper- does not start (see below). will start to take snapshots after or snapper- should start without intervention after a reboot. journalctl -u snapper- systemctl status snapper- snapper- is not listed in journalctl -u snapperd.service snapper list <!-- 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. Maintainer information:
correctly starts snapper- after a (manual) reboot. The new snapshotOnBoot option is working as well. Reboot after a system upgrade has not been testet yet.
snapper- fails to restart after a system upgrade, but snapshotOnBoot works as expected. systemctl status snapper- journalctl -u snapper- snapper list
Change:
inherit debugInfo; buildFlags = if debugInfo <del> then "ERL_COMPILER_OPTIONS=debug_info" else ""; </del> <ins> then "ERL_COMPILER_OPTIONS=debug_info" else ""; </ins> preBuild = '' # The build process uses ./rebar. Link it to the nixpkgs rebar

Discussion:
When installing latest Elixir with Erlang 20 via , several of these warnings are emitted through the build process: I'm installing through with (on Vultr FWIW). Though I believe on a new system may be enough to reproduce. The only way I've gotten the warnings to subside if by specifying . System: Nix version: Nixpkgs version: Sandboxing enabled:
/cc: (by request from )
I will look into this.
I see that you have dropped the override. Is this because of these are just harmless warnings? I've switched to the same nixpkgs and could not reproduce the warnings on Ubuntu: Output is here: I'll try to reproduce this on NixOS machine now.
I was able to reproduce this on NixOS machine:
Thanks
Change:
py = python3.override { # Put packageOverrides at the start so they are applied after defaultOverrides <del> packageOverrides = lib.foldr lib.composeExtensions (self: super: { }) (defaultOverrides); </del> <ins> packageOverrides = lib.foldr lib.composeExtensions (self: super: { }) defaultOverrides; </ins> }; in

Discussion:
, CVSSv3=4.3 (nixos-21.11) archivy is vulnerable to Cross-Site Request Forgery (CSRF) Scanned versions: nixos-21.11: . Cc
Change:
description = "Utility to detect other OSs on a set of drives"; homepage = "http://packages.debian.org/source/sid/os-prober"; license = licenses.gpl2Plus; <ins> mainProgram = "os-prober"; </ins> maintainers = with maintainers; [ symphorien ]; <ins> platforms = platforms.linux; </ins> }; }

Discussion:
In , under Platforms, it is reported: but it should have at least one compatible platform. Fix the webpage with the correct information. <!-- make sure this issue is not redundant or obsolete --- [X] checked [latest Nixpkgs manual] ([source][nixpkgs-source]) and [latest NixOS manual] ([source][nixos-source]) [X] checked [open documentation issues] for possible duplicates [X] checked [open documentation pull requests] for possible solutions [latest Nixpkgs manual]: [latest NixOS manual]: [nixpkgs-source]: [nixos-source]: [open documentation issues]: [open documentation pull requests]:
Change:
stdenv.mkDerivation { name = isoName; builder = ./make-iso9660-image.sh; <del> buildInputs = [ xorriso syslinux zstd ]; </del> <ins> buildInputs = [ xorriso syslinux zstd libossp_uuid ]; </ins> inherit isoName bootable bootImage compressImage volumeID efiBootImage efiBootable isohybridMbrImage usbBootable;

Discussion:
Describe the bug When building twice, the GPT partition has a different GUID. To Reproduce Steps to reproduce the behavior: to see the GUID is not consistent (or at , ) Expected behavior A deterministic GUID Additional context For additional background on why it's helpful for builds to be reproducible, see https://reproducible- I'd be happy to help hunt down and fix this problem further, but this is rather new territory for me, so I'd appreciate any help
Thanks for taking a look at this! I'd suggest to trace it down from , and how things are passed down to - but I'm not exactly sure WHAT creates the GPT partition.
Thanks for the encouragement! Looking closer, it seems the GPT is written by as invoked in . Unfortunately, while manually invoking with fewer flags and indeed has the expected effect, adding that flag to the invocation doesn't. Some more digging to do! :)
Ah it's somehow the post-processing... indeed that seems to generate a new random UUID with . Without it keeps it intact. I wonder if we need the , given already seems to do quite a bit of the work.
Shouldn't this be testable by trying to boot an image without that flag being set on a pure UEFI system?
I tested this by copying the ISO built without that flag to an USB disk, and booting my laptop with the "UEFI: USB disk" selected in the boot priorities. That worked fine. I'll try to prepare a PR that makes the GPT disk GUID static (based on the derivation hash or ) and skips the . (though not sure when I'll get to it, if someone wants to beat me to it, feel free ;) )
Cool, this sounds very promising, also is one more step towards :-) cc yeah, just hashing over the input hash and converting that to the uuid format somehow sounds reasonable.
Change:
# Remove unnecessary groff reference from runtime closure, since it's big sed -i '/NROFF/d' $out/lib/ruby/*/*/rbconfig.rb ${ <del> lib.optionalString removeReferenceToCC '' </del> <ins> lib.optionalString (!jitSupport) '' </ins> # Get rid of the CC runtime dependency ${removeReferencesTo}/bin/remove-references-to  -t ${stdenv.cc}  $out/lib/libruby* <ins> ${removeReferencesTo}/bin/remove-references-to  -t ${stdenv.cc}  $out/${passthru.libPath}/${stdenv.targetPlatform.system}/rbconfig.rb </ins> '' } # Bundler tries to create this directory

Discussion:
Describe the bug I'm hunting down packages that reference gcc. One of them is (maintainers: & ). Here's why: The fault is the fact that the build flag doesn't remove all references, as one might expect (EDIT, see: ). I'm up to including this feature, but I was wondering perhaps it'd be legit to disable this feature for the derivation? I opened a PR at (EDIT).
But that would mean gems that require a compiler would no longer work.
The suggestion is for , not . Isn't the derivation that's used to build the gems? According to:
It still has support for gems, so some will fail with gcc. What exactly is the use case for ?
Technically it's not used anywhere, according to .
I'd like to make my - with an overlay. The goal is to make the 1 or 2 pure ruby scripts I have on my system not pull , as they do today.
But what is the reason? You're likely to have a version of ruby that includes gcc on your system anyway, so you don't really save any space. And the use-case would be plain ruby scripts with only the gems that don't require system libraries. We have no users in nixpkgs of presumably because it's rather pointless. And while of course we can strip gcc from rubyMinimal (there's no harm), I'd rather say drop instead.
Not If I'll apply and this overlay: This allows me to not need GCC for for example - which is the only ruby gem I use. For example, run with this PR and that overlay applied: And you should get: And without , (and without the overlay because it would fail) you should get: is the only derivation that needs ruby that I actually use. I've updated the 1st comment in to exemplify this overlay as a possible usecase. Well I tend to agree - even for asciidoctor which should be pretty much a pure ruby gem, it still required and which aren't enabled in current . Hence I tend to agree. OK so I've updated to include a drop to , including release notes and an alias. Waiting for your review :crossed_fingers: .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
# causes redefinition of _FORTIFY_SOURCE hardeningDisable = [ "fortify3" ]; <del> # Packages to prefix to the Apptainer/Singularity container runtime default PATH # Use overrideAttrs to override </del> <ins> # Packages to provide fallback bin paths # to the Apptainer/Singularity container runtime default PATHs. # Override with `<pkg>.overrideAttrs`. </ins> defaultPathInputs = [ bash coreutils

Discussion:
Nixpkgs's package of Sylabs SingularityCE () now fails to execute image. After initial examination, the known cause is the failure to substitute default FHS s for some files, but the fix is WIP. Steps to reproduce the behavior: error. should succeed. If applicable, add screenshots to help explain your problem. 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]:
singularity isn't supposed to work without setuid?
Yup. The error seems to result from failure to replace all the default paths after source file hierarchy changes.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
{ fetchurl, fetchpatch, stdenv, lib, pkgconfig <del> , libgpgerror, libassuan, libcap ? null, libsecret ? null, ncurses ? null, gtk2 ? null, gcr ? null, qt4 ? null </del> <ins> , libgpgerror, libassuan, libcap ? null, libsecret ? null, ncurses ? null, gtk2 ? null, gcr ? null, qt ? null </ins> }: let

Discussion:
Setting breaks . The reason being that defines and as follows: Which then overrides with, Resulting in an infinite loop. This appears to be a regression due to . Set , try to build . Using .
This is downfall from
what should be done about this?
Did not we fix this in Anyway, should fix pinentry for good.
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 .
how does the situation look like now? Is this specific issue fixed?
I marked this as stale due to inactivity. &rarr;
Closing due to inactivity. Please reopen if it's still broken.
Change:
stdenv.mkDerivation (finalAttrs: { pname = "carla"; <del> version = "2.5.6"; </del> <ins> version = "2.5.7"; </ins> src = fetchFromGitHub { owner = "falkTX"; repo = finalAttrs.pname; rev = "v${finalAttrs.version}"; <del> hash = "sha256-/ZIproky1AHJHvV62xWm0nrzNBOjvBBv93V0KespVjU="; </del> <ins> hash = "sha256-WDwYfDR760Maz3oWNPcPbl8L+0MIRbeqNVGH9Gg4ZYc="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: carla Latest released version: 2.5.7 Current version on the unstable channel: 2.5.6 Current version on the stable/release channel: 2.5.5 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Change:
<del> { lib, buildPythonPackage, fetchFromGitHub, pytestCheckHook, pythonOlder, pythonAtLeast, setuptools, distutils, }: buildPythonPackage rec { pname = "tree-sitter0_21"; version = "0.21.3"; pyproject = true; disabled = pythonOlder "3.7"; src = fetchFromGitHub { owner = "tree-sitter"; repo = "py-tree-sitter"; rev = "refs/tags/v${version}"; hash = "sha256-HT1sRzDFpeelWCq1ZMeRmoUg0a3SBR7bZKxBqn4fb2g="; fetchSubmodules = true; }; build-system = [ setuptools ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "tree_sitter" ]; # Needed explicitly for Python >= 3.12 as tree-sitter provides # calls to distutils functions to compile language files dependencies = lib.optionals (pythonAtLeast "3.12") [ distutils ]; preCheck = '' rm -r tree_sitter ''; meta = with lib; { description = "Python bindings to the Tree-sitter parsing library"; homepage = "https://github.com/tree-sitter/py-tree-sitter"; changelog = "https://github.com/tree-sitter/py-tree-sitter/releases/tag/v${version}"; license = licenses.mit; maintainers = with maintainers; [ fab ]; }; } </del>

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:
* Format the commits in the following way: <del> `(pkg-name | service-name): (from -> to | init at version | refactor | etc)` </del> <ins> ``` (pkg-name | service-name): (from -> to | init at version | refactor | etc) (Motivation for change. Additional information.) ``` </ins> Examples: * nginx: init at 2.0.1 * firefox: 3.0 -> 3.1.1 * hydra service: add bazBaz option <ins> Dual baz behavior is needed to do foo. </ins> * nginx service: refactor config generation <ins> The old config generation system used impure shell scripts and could break in specific circumstances (see #1234). </ins> * `meta.description` should: * Be capitalized

Discussion:
Nixpkgs already has some guidelines how to write commit messages in It describes how to structure the message. Most commits follow this guideline which is very good. However one Problem is that many people do really good changes in their commit but for somebody not directly involved it is really hard to understand why. In my opinion it's very important to have this "why" in the commit message, especially if the project has many collaborators of various degree of involvement. One project I found to do this very well is . I propose to add a section to that encourages to explain a bit more why the changes were made. Maintainers should then encourage people to follow this guidelines when reviewing PRs.
Do you have any special kind of commits in mind? I am asking because package updates and new package commits seems pretty much self-explanatory. (one improvement I can see in this regard is to put release notes for package updates commits) Also, the why, while not in mandatory in the commit message, should figure in the pull-request .
I recently stumbled upon this commit for example: While the commit message clearly states what is done, I have no Idea why it was done. Having the motivation in the pull request is good but doing self contained commits with all the information for somebody to understand the changes and the reasons behind is even better.
I second that the motivation should be in the commit message and not only the pr, so one can read it without searching for the pr on github first..
Change:
${cfg.monitorSection} EndSection <del> Section "InputClass" Identifier "Keyboard catchall" MatchIsKeyboard "on" Option "XkbModel" "${cfg.xkbModel}" Option "XkbLayout" "${cfg.layout}" Option "XkbOptions" "${cfg.xkbOptions}" Option "XkbVariant" "${cfg.xkbVariant}" EndSection </del> # Additional "InputClass" sections ${flip concatMapStrings cfg.inputClassSections (inputClassSection: '' Section "InputClass"

Discussion:
I have no idea if this is a problem, but i seems suspicious, especially since I've been looking into some odd keyboard issues lately. Run . I would expect this to have the value of in the final bit ( in my case). System: 18.03pre116572. (Impala) Nix version: 1.11.5 Nixpkgs version: 18.03pre116572. Sandboxing enabled: yes
Change:
userData = null; script = '' machine.start() <ins> # Test that if contents includes a file, it is copied to the target. </ins> assert "content" in machine.succeed("cat /testFile") fileDetails = machine.succeed("ls -l /testFile") assert "1234" in fileDetails assert "5678" in fileDetails assert "rwxr-xr-x" in fileDetails <ins> # Test that if contents includes a directory, it is copied to the target. dirList = machine.succeed("ls /testDir") assert "image-contents.nix" in dirList </ins> ''; }

Discussion:
takes an argument that copies source paths into the resulting VM image. It seems to work fine when the sources are files or , but when copying directories, they end up nested inside the target directory named with a nix-store-like path. This is not what I expected, it is hard to use, and I do not think it is the intended behavior. these files: (and additional , see attached ). the VM image with . the VM image, e.g. with . in with credentials literal . that contains a subdirectory with a Nix-store-like path, e.g. instead of . I expected that the source would end up at the target, as happens with contents objects that are files. ! I will have a PR with a test and fix up soon. When changing the behavior of a function that is already widely used, even fixing a bug can cause problems for people. I checked, but I did not find any existing usages of with directories in . And given how broken the directory support seems, I suspect that it is not actually used in the wild, so I think it is okay to fix this behavior. Please run and paste the result.