jiebi/CodeConvo huggingface dataset:
Code change:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

Related discussion:
text: "CC=${stdenv.cc.targetPrefix}cc" "STRIP="  # Disable install stripping as it breaks cross-compiling. We strip binaries anyway in fixupPhase. "prefix=${placeholder "out"}" <del> "sysconfdir=${placeholder "out"}/etc" </del> <ins> "sysconfdir=/etc" </ins> "systemdsystemunitdir=${placeholder "out"}/lib/systemd/system" # contrib modules require these "moduledir=${placeholder "out"}/lib/modules"
Code change:
The system-wide LDAP client configuration in is ignored by Openldap client programs. Steps to reproduce the behavior: settings into via or any other Openldap client Openldap client programs should obey the system-wide configuration file in . strace shows it's reading the example configuration from the package instead: Since commit the openldap package no longer passes to configure, it only passes to make instead. Please run and paste the result.
It seems a bit dodgy, but this might be a solution: plus corresponding changes to all the packages and tests that refer to . I'm just rebuilding a gazillion packages on my system from source, so I can check if that works properly...
you probably meant to ping and instead
Oops, sorry about that. I forgot that the maintainer handles listed in the package do not necessarily correspond to their Github usernames.
I realised that changing is probably unwise. Not only does it break some other packages (like python-ldap) and some Nixos tests, it will also break any users who have configured slapd to refer to the schemas under , as I myself have: And changing is not necessary to fix the bug anyway. It seems that the approach of passing differently in compile and install works. I'll send a PR for it.

Related discussion:
text: installFlags = [ "prefix=${placeholder "out"}" <ins> "sysconfdir=${placeholder "out"}/etc" </ins> "moduledir=${placeholder "out"}/lib/modules" "INSTALL=install" ];
Code change:
The change to use at broke evaluation of The expression was changed to reference but that is undefined. It evaluates and builds with the following change? What I'm not sure about is if this is all that is required or if there is anything more before I submit a PR. System: (Flounder) Nix version: nix-env (Nix) 1.11.3 Nixpkgs version: (local git checkout with patches)
Also I'm not sure if any of the other expressions changed were similarly affected. Quickly testing the expression appeared to evaluate successfully despite not having as an input.

Related discussion:
text: { stdenv, fetchurl, gmp }: stdenv.mkDerivation rec { <del> name = "ikarus-0.0.3"; </del> <ins> version = "0.0.3"; name = "ikarus-${version}"; </ins> src = fetchurl { <del> url = "http://ikarus-scheme.org/${name}.tar.gz"; </del> <ins> url = "http://launchpad.net/ikarus/0.0/${version}/+download/${name}.tar.gz"; </ins> sha256 = "0d4vqwqfnj39l0gar2di021kcf6bfpkc6g40yapkmxm6sxpdcvjv"; };
Code change:
Per the , can only be installed on 32-bits systems. Is this still correct? It's a rather old expression, and given that other 32-bits software can be installed on 64-bits NixOS just fine, I'm not sure whether this needs to be changed.
I think there was another attribute for as well, but I am not sure about that.
this should be documented actually
Or the expression could be fixed to transparently install the 32-bit version. Like this does (I think):
You might be refering to there?
I thought there was also something called without the part but I guess I am wrong with that. In any case, the solution proposes looks like a good one?
Does the package work actually? I'm trying to test it, but it seems to be downloading forever.
OK, it seems to play fine.

Related discussion:
text: { stdenv, fetchurl, gmp }: stdenv.mkDerivation rec { <del> name = "ikarus-0.0.3"; </del> <ins> version = "0.0.3"; name = "ikarus-${version}"; </ins> src = fetchurl { <del> url = "http://ikarus-scheme.org/${name}.tar.gz"; </del> <ins> url = "http://launchpad.net/ikarus/0.0/${version}/+download/${name}.tar.gz"; </ins> sha256 = "0d4vqwqfnj39l0gar2di021kcf6bfpkc6g40yapkmxm6sxpdcvjv"; };
Code change:
<!-- 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: minio <!-- 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: 2022-05-08 desired version: 2022-07-15 <!-- 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.

Related discussion:
text: in buildGoModule rec { pname = "minio"; <del> version = "2022-05-08T23-50-31Z"; </del> <ins> version = "2022-07-17T15-43-14Z"; </ins> src = fetchFromGitHub { owner = "minio"; repo = "minio"; rev = "RELEASE.${version}"; <del> sha256 = "sha256-Ssuqk/ax6MWdXtbJqWeTTtsIiTK4FmYSR5rOqxh+IaU="; </del> <ins> sha256 = "sha256-hQ52fL4Z3RHthHaJXCkKpbebWpq8MxHo4BziokTuJA4="; </ins> }; <del> vendorSha256 = "sha256-JoI3B3rDzlY0lDHF3rjrzv8/Rq+XCFRs35bWVZqfAKA="; </del> <ins> vendorSha256 = "sha256-u36oHqIxMD3HRio9A3tUt6FO1DtAcQDiC/O54ByeNyg="; </ins> doCheck = false;
Code change:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

Related discussion:
text: <del> { lib, stdenv, fetchFromGitHub, makeDesktopItem, makeWrapper, ant, jdk, jre, gtk2, glib, xorg, Cocoa }: </del> <ins> { lib, stdenv, fetchFromGitHub, makeDesktopItem, makeWrapper, wrapGAppsHook, ant, jdk, jre, gtk2, glib, xorg, Cocoa }: </ins> let _version = "2.10.2";
Code change:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

Related discussion:
text: pname = "jameica"; inherit version; <del> nativeBuildInputs = [ ant jdk makeWrapper ]; </del> <ins> nativeBuildInputs = [ ant jdk wrapGAppsHook makeWrapper ]; </ins> buildInputs = lib.optionals stdenv.isLinux [ gtk2 glib xorg.libXtst ] ++ lib.optional stdenv.isDarwin Cocoa;
Code change:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

Related discussion:
text: sha256 = "1x9sybknzsfxp9z0pvw9dx80732ynyap57y03p7xwwjbcrnjla57"; }; <ins> dontWrapGApps = true; </ins> # there is also a build.gradle, but it only seems to be used to vendor 3rd party libraries # and is not able to build the application itself buildPhase = ''
Code change:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

Related discussion:
text: install -Dm644 plugin.xml $out/share/java/ install -Dm644 build/jameica-icon.png $out/share/pixmaps/jameica.png cp ${desktopItem}/share/applications/* $out/share/applications/ <ins> ''; postFixup = '' </ins> makeWrapper ${jre}/bin/java $out/bin/jameica  --add-flags "-cp $out/share/java/jameica.jar:$out/share/jameica-${version}/* ${ lib.optionalString stdenv.isDarwin ''-Xdock:name="Jameica" -XstartOnFirstThread'' } de.willuhn.jameica.Main"  --prefix LD_LIBRARY_PATH : ${lib.escapeShellArg (lib.makeLibraryPath buildInputs)}  <del> --chdir "$out/share/java/" </del> <ins> --chdir "$out/share/java/"  "''${gappsWrapperArgs[@]}" </ins> ''; meta = with lib; {
Code change:
When a user starts and opens a file dialog the application crashes with (Jameica 2.10.2:): GLib-GIO-ERROR **: 22:23:21.974: No GSettings schemas are installed on the system Steps to reproduce the behavior: jameica a "workspace" -manage backups -restore different backup Opens a gtk file dialog jameica crashes on every file dialog for me. the backup path is just the easiest accessible and something a user may come along quickly. i was already playing around a bit with the wrapGAppsHook, but i just dont get it running atm. so maybe someone else want to take a look on that. i am running a kde session on wayland, but i doubt that it make any difference on gnome or other DE. <!-- 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.
created a pr for it. my first tries in adding wrapGappsHook did fail as i did not get, that the order for nativeBuildinputs do matter.

Related discussion:
text: ''; sourceProvenance = with sourceTypes; [ fromSource <del> binaryBytecode  # source bundles dependencies as jars </del> <ins> binaryBytecode # source bundles dependencies as jars </ins> ]; license = licenses.gpl2Plus; platforms = [ "x86_64-linux" "i686-linux" "x86_64-darwin" ];
Code change:
<!-- 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: tutanota-desktop <!-- 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: 3.95.4 desired version: 3.98.15 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Version 3.95.4 is not supported by Tutao GmbH anymore. I don't know how that exactly works with Nixpkgs, but it would be desirable to update tutanota in the stable 22.05 channel too. Please tag this issue in your PR.

Related discussion:
text: stdenv.mkDerivation rec { pname = "tutanota-desktop"; <del> version = "3.95.4"; </del> <ins> version = "3.98.15"; </ins> src = fetchurl { url = "https://github.com/tutao/tutanota/releases/download/tutanota-desktop-release-${version}/${pname}-${version}-unpacked-linux.tar.gz"; name = "tutanota-desktop-${version}.tar.gz"; <del> sha256 = "0kkkp0nw4fby4663w7g0k2y1sg89pm336slzii1s3n70h8cak3dx"; </del> <ins> sha256 = "sha256-yuSFDLQ7ckuZYuXREbW0VvMapzO2VhVIH1Ccr1uQHmo="; </ins> }; nativeBuildInputs = [
Code change:
name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

Related discussion:
text: { lib, appimageTools, fetchurl, nodePackages }: let pname = "flexoptix-app"; <del> version = "5.11.0"; name = "${pname}-${version}"; </del> <ins> version = "5.12.1"; </ins> src = fetchurl { <del> name = "${name}.AppImage"; </del> <ins> name = "${pname}-${version}.AppImage"; </ins> url = "https://flexbox.reconfigure.me/download/electron/linux/x64/FLEXOPTIX%20App.${version}.AppImage"; <del> hash = "sha256-Nj6S53b4w84qppkGB7lMpJhJlxifaD4acPryuZxY7cM="; </del> <ins> hash = "sha256-ugnJcSFgEEPJ9qxqmRGgW1fraE4E/HbbxpK/00TXPmw="; </ins> }; udevRules = fetchurl {
Code change:
name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

Related discussion:
text: hash = "sha256-OZe5dV50xq99olImbo7JQxPjRd7hGyBIVwFvtR9cIVc="; }; <del> appimageContents = (appimageTools.extract { inherit name src; }).overrideAttrs (oA: { </del> <ins> appimageContents = (appimageTools.extract { inherit pname version src; }).overrideAttrs (oA: { </ins> buildCommand = '' ${oA.buildCommand}
Code change:
name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

Related discussion:
text: }); in appimageTools.wrapAppImage { <del> inherit name; </del> <ins> inherit pname version; </ins> src = appimageContents; multiPkgs = null; # no 32bit needed
Code change:
name: flexoptix-app current version: 5.11.0 desired version: 5.12.1 maintainers: Please tag this issue in your PR.

Related discussion:
text: extraInstallCommands = '' # Add desktop convencience stuff <del> mv $out/bin/{${name},${pname}} </del> <ins> mv $out/bin/{${pname}-*,${pname}} </ins> install -Dm444 ${appimageContents}/flexoptix-app.desktop -t $out/share/applications install -Dm444 ${appimageContents}/flexoptix-app.png -t $out/share/pixmaps substituteInPlace $out/share/applications/flexoptix-app.desktop
Code change:
Steps to reproduce the behavior: See . Regression of Blocks: Blocks: porting GSound and GNOME Clocks to macOS Notify upstream: libproxy/libproxy <!-- 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.
A possible fix:
That looks like an upstream bug – the build system should never use functions it is undefining. And either way, on Darwin, I would expect system JavaScriptCore to be used instead of Duktape.

Related discussion:
text: <del> { lib, stdenv </del> <ins> { lib , stdenv </ins> , fetchFromGitHub <ins> , fetchpatch </ins> , pkg-config , cmake , zlib
Code change:
Steps to reproduce the behavior: See . Regression of Blocks: Blocks: porting GSound and GNOME Clocks to macOS Notify upstream: libproxy/libproxy <!-- 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.
A possible fix:
That looks like an upstream bug – the build system should never use functions it is undefining. And either way, on Darwin, I would expect system JavaScriptCore to be used instead of Duktape.

Related discussion:
text: hash = "sha256-pqj1LwRdOK2CUu3hYIsogQIXxWzShDuKEbDTbtWkgnQ="; }; <ins> patches = lib.optionals stdenv.isDarwin [ # https://github.com/libproxy/libproxy/pull/189 (fetchpatch { url = "https://github.com/libproxy/libproxy/commit/4331b9db427ce2c25ff5eeb597bec4bc35ed1a0b.patch"; sha256 = "sha256-uTh3rYVvEke1iWVHsT3Zj2H1F+gyLrffcmyt0JEKaCA="; }) ]; </ins> outputs = [ "out" "dev" "py3" ]; nativeBuildInputs = [
Code change:
Steps to reproduce the behavior: git-town on MacOS Please run and paste the result.

Related discussion:
text: <del> { lib, buildGoModule, fetchFromGitHub, installShellFiles, git, testers, git-town, makeWrapper }: </del> <ins> { lib, buildGoModule, fetchFromGitHub, fetchpatch, installShellFiles, git, testers, git-town, makeWrapper }: </ins> buildGoModule rec { pname = "git-town"; <del> version = "7.7.0"; </del> <ins> version = "7.8.0"; </ins> src = fetchFromGitHub { owner = "git-town"; repo = "git-town"; rev = "v${version}"; <del> sha256 = "sha256-FpBEBx2gb33fGDndvZmvG1A61NoJ4Qy4V3YQSb+Ugsc="; </del> <ins> sha256 = "sha256-g9ooMIMN8DN2FcWYkDC1hICCleQYdHf30PYMCit/NMI="; </ins> }; <ins> patches = [ # Fix "go vet" when building using Go 1.18. (fetchpatch { name = "fix-go-vet-in-go-1.18.patch"; url = "https://github.com/git-town/git-town/commit/23eb0aca7b28c6a0afc21db553aa0e35d35891aa.patch"; sha256 = "sha256-EyfhKVrQxRJNrYqaZI04dJogaXs1J+bbOIu7p8g2Clc="; }) ]; </ins> vendorSha256 = null; nativeBuildInputs = [ installShellFiles makeWrapper ];
Code change:
If I try to run Solaar via Rofi nothing happens, when trying it via terminal the following error occurred: If I open a nix-shell with and run solaar it opens and works without issues. Relevant configuration: Steps to reproduce the behavior: system from unstable to run solaar Solaar GUI main windows opens I've tried to find out more and was directed from that it could be related to missing but regardless where I it it didn't solve the issue. Please run and paste the result. nixos-unstable -
see
Thanks :)

Related discussion:
text: outputs = [ "out" "udev" ]; <del> nativeBuildInputs = [ wrapGAppsHook gdk-pixbuf ]; buildInputs = [ libappindicator librsvg ]; </del> <ins> nativeBuildInputs = [ gdk-pixbuf gobject-introspection wrapGAppsHook ]; buildInputs = [ libappindicator librsvg ]; </ins> propagatedBuildInputs = with python3Packages; [ evdev <del> gobject-introspection </del> gtk3 psutil pygobject3
Code change:
If I try to run Solaar via Rofi nothing happens, when trying it via terminal the following error occurred: If I open a nix-shell with and run solaar it opens and works without issues. Relevant configuration: Steps to reproduce the behavior: system from unstable to run solaar Solaar GUI main windows opens I've tried to find out more and was directed from that it could be related to missing but regardless where I it it didn't solve the issue. Please run and paste the result. nixos-unstable -
see
Thanks :)

Related discussion:
text: install -Dm444 -t $udev/etc/udev/rules.d rules.d-uinput/*.rules ''; <ins> dontWrapGApps = true; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; # no tests doCheck = false; pythonImportsCheck = [ "solaar" ]; </ins> meta = with lib; { description = "Linux devices manager for the Logitech Unifying Receiver"; longDescription = ''
Code change:
Putting this out here in case anybody else is seeing this. On am Acer Swift SF314-43, the touchpad goes missing with kernel 5.19. Works again with kernel 5.18 and no other changes. Steps to reproduce the behavior: to kernel 5.19 that it's broken With kernel 5.18: With kernel 5.19:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This happended to me as well, on a Tuxedo Aura Gen 1 with an ElanTech clickpad and NixOS 22.05. Comparing the output of between kernel 5.18 and 5.19 I found three modules, which haven't been loaded on 5.19: , and . ~I them to , ran and after rebooting the touchpad is working again.~ Adding them to in my NixOS configuration did not help. Edit: Was on the wrong kernel version, when testing if manually adding the modules would help.
Ah, on 5.19: Kernel rebuilding time. Haven't done that in a while...
So that did it. I didn't need to specify the list of modules, only add the kernel option.
That fixed it on my Tuxedo as well.

Related discussion:
text: MOUSE_PS2_VMMOUSE  = yes; MTRR_SANITIZER     = yes; NET_FC             = yes; # Fibre Channel driver support <ins> # Needed for touchpads to work on some AMD laptops PINCTRL_AMD        = whenAtLeast "5.19" yes; </ins> # GPIO on Intel Bay Trail, for some Chromebook internal eMMC disks PINCTRL_BAYTRAIL   = yes; # GPIO for Braswell and Cherryview devices