jiebi/CodeConvo huggingface dataset:
Code change:
dbtype = "pgsql"; dbname = "nextcloud"; dbuser = "nextcloud"; <del> dbhost = "localhost"; dbpassFile = toString (pkgs.writeText "db-pass-file" '' hunter2 ''); </del> <ins> dbhost = "/run/postgresql"; </ins> inherit adminuser; adminpassFile = toString (pkgs.writeText "admin-pass-file" '' ${adminpass}

Related discussion:
text: Well, for the record it was actually idea :sweat_smile: I guess so, all the stuff from is also in my at the moment. I'll probably have sufficient time next weekend to check if I can trigger such a case. I can't promise that, but unless anybody beats me, I can hopefully prepare a fix for this :)
Did you gain some new insights on this?
Unfortunately not... I was pretty busy back then. But as this only requires some fiddling in the module and no patching of the actual package, the change shouldn't be too painful, so if you'd like to take over... :sweat_smile:
there's with a fix now :)
Code change:
''; }); }); <ins> mozc = super.mozc.overrideAttrs (attrs: { postPatch = attrs.postPatch or "" + '' substituteInPlace src/unix/emacs/mozc.el  --replace '"mozc_emacs_helper"' '"${pkgs.ibus-engines.mozc}/lib/mozc/mozc_emacs_helper"' ''; }); </ins> }; in lib.mapAttrs (n: v: if lib.hasAttr n overrides then overrides.${n} else v) super);

Related discussion:
text: Emacs mozc looks to only package the file, but it requires other binaries to work. Specifically 'mozcemacshelper' is required for it to run, as well as the mozcserver. I suppose the server can be installed with ibus-mozc, or fcitx-mozc, etc, but either way I did not find 'mozcemacs_helper'. Steps to reproduce the behavior: emacs to require it - and run mozc Japanese input via the Mozc IME should be functional <!-- 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 made a patch Could you try it?
I have a feeling this will not work for you now due to Apparently just changed paths (it's in now under the ibus-mozc store path). So I think it should continue to work as long as the emacs variable is updated. (I'm using fcitx5 so it didn't hit me, but I came across this by chance and thought I should let you know)
Code change:
wrap ${targetPrefix}gfortran $wrapper $ccPath/${targetPrefix}gfortran ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}g77 ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}f77 <ins> export named_fc=${targetPrefix}gfortran </ins> '' + optionalString cc.langJava or false ''

Related discussion:
text: Describe the bug To Reproduce Expected behavior The derivation to build an executable called Additional context It fails with also but succeeds with but so 1.3 seems to be a recent addition even though julia is on 1.4 and about to move to 1.5. Notify maintainers Metadata Please run and paste the result.
Same issue here: system: host os: multi-user?: sandbox: version: channels(root): channels(jfelice): nixpkgs: This prevents installing GNU octave on MacOS.
FWIW I was able to work around this issue by creating a to disable the checks in arpack: I was able to build octave successfully with that. I had to hack around a runtime issue finding , will log that as a separate issue.
Code change:
wrap ${targetPrefix}gfortran $wrapper $ccPath/${targetPrefix}gfortran ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}g77 ln -sv ${targetPrefix}gfortran $out/bin/${targetPrefix}f77 <ins> export named_fc=${targetPrefix}gfortran </ins> '' + optionalString cc.langJava or false ''

Related discussion:
text: Describe the bug I'd like to build the python numpy package on an x86 machine for the armv7 architecture. numpy requires liblapack and blas, which require gfortran I already fixed one issue which is that liblapack couldn't find the gfortran compiler (see the overlay below) I'm trying to use the 20.03 release, latest commit. Here's what I'm running exactly: To Reproduce Steps to reproduce the behavior: -build here's the error I get Expected behavior The derivation builds Metadata Please run and paste the result. Maintainer information:
Maybe related to: ?
I'm not getting this in NixOS. It looks like a sandboxing issue. Can you try running this:
Thanks for responding! I launched this build on NixOs using an AMI on EC2 and I get the same result as in the issue report, here are the system details:
A similar issue exists on unstable when building for x86. Currently on: system: host os: multi-user?: sandbox: version: channels(root): channels(swflint): nixpkgs:
Code change:
security.pam.services.sddm.enableKwallet = true; security.pam.services.slim.enableKwallet = true; <ins> xdg.portal.extraPortals = [ pkgs.xdg-desktop-portal-kde ]; </ins> # Update the start menu for each user that is currently logged in system.userActivationScripts.plasmaSetup = '' # The KDE icon cache is supposed to update itself

Related discussion:
text: It is possible to use Plasma’s native file dialogues in Firefox 64 to open or save a file. Currently this feature is not working in NixOS, and it seems to me some small changes would need to be made to derivation in order to enable it. I propose we include this option together with as a Firefox option in NixOS (see also: ). I followed the explanation on how to enable this feature as it was published on : Firefox (64 is current stable) from a terminal emulator But it produces the following error: system: host os: multi-user?: sandbox: version: channels(root): channels(hook): nixpkgs:
You'll probably have to do something like this to expose the dbus service:
Where? In:
It needs to go into a nixos module or your .
Code change:
MODULE_COMPRESS    = yes; MODULE_COMPRESS_XZ = yes; <del> KERNEL_XZ          = yes; </del> <ins> # use zstd for kernel compression if newer than 5.9, else xz. KERNEL_XZ          = whenOlder "5.9" yes; KERNEL_ZSTD        = whenAtLeast "5.9" yes; </ins> SYSVIPC            = yes;  # System-V IPC

Related discussion:
text: The latest major version 5.9 of the Linux kernel . Apparently, zstd compressed things decompress much faster and can cut boot times substantially, hence it seems worthwhile for us to support this scheme. Currently we are using bzip2. Unfortunately, I probably won't find time to work on this myself, but thought to open this issue to track progress.
I've [probably] been using it through a xanmod patch, not recently since the 5.9 release though. What I have in my files are and adding to of the kernel derivation
For the initrd image: For me (which might differ from the stock kernel NixOS provides): is already enabled, so set This enables ZSTD compression for initrd. However, which will need to as mentioned above.
I was wondering if zstd should be made a part of stdenv. are all available in stdenv on linux and with slowly becoming more common by being available in the kernel and used by various distribution's packaging it should make sense to include it.
Can this be closed? Did cover it all?
Yes, it did! Closing this issue. Thank you for pointing that out, didn't notice before.
Code change:
<del> { stdenv, systemd, polkit, fetchFromGitHub, buildGoPackage, m4}: </del> <ins> { stdenv, fetchFromGitHub, buildGoPackage, m4 }: </ins> buildGoPackage rec { name = "localtime-2017-11-07";

Related discussion:
text: I've just set on my laptop while on holiday. The timezone never updates (tried restarting, waiting a while). Running I see: I see in that the service is run as the user. If I run: I also see the message . Whereas if I run there is no output and the timezone immediately updates (as shown by an immediate change in the time in my status bar, and confirmed by running ). It seems that the user just doesn't have permission to set the timezone. in (and unset ) to see if timezone changes , look for messages with "Failed to set timezone" (will only appear if the timezone it would need to set is different than the current timezone) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
It worked for me after a reboot. Maybe the polkit rules are not getting appliead during a ?
Code change:
<del> { lib, fetchpatch, python3, postfix, lynx </del> <ins> { lib , fetchpatch , python3 , docutils , sphinx , postfix , lynx </ins> }: with python3.pkgs; buildPythonPackage rec { pname = "mailman"; <del> version = "3.3.5"; </del> <ins> version = "3.3.8"; </ins> disabled = pythonOlder "3.6"; src = fetchPypi { inherit pname version; <del> sha256 = "12mgxs1ndhdjjkydx48b95na9k9h0disfqgrr6wxx7vda6dqvcwz"; </del> <ins> hash = "sha256-g6wH7lXqK0yJ8AxO1HFxMvBicBJ9NGWlPePFyxl9Qc4="; </ins> }; propagatedBuildInputs = with python3.pkgs; [

Related discussion:
text: Steps to reproduce the behavior: $ nix build --verbose The interesting thing is that I can build the flask-sqlalchemy package just fine: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Code change:
#  allow for plugin update check, but no calibre version check (fetchpatch { name = "0001-only-plugin-update.patch"; <del> url = "https://raw.githubusercontent.com/debian-calibre/calibre/debian/${version}%2Bdfsg-1/debian/patches/0001-only-plugin-update.patch"; </del> <ins> url = "https://raw.githubusercontent.com/debian-calibre/calibre/debian/${version}-1/debian/patches/0001-only-plugin-update.patch"; </ins> hash = "sha256-uL1mSjgCl5ZRLbSuKxJM6XTfvVwog70F7vgKtQzQNEQ="; }) (fetchpatch { <del> name = "0007-Hardening-Qt-code.patch"; url = "https://raw.githubusercontent.com/debian-calibre/calibre/debian/${version}%2Bdfsg-1/debian/patches/0007-Hardening-Qt-code.patch"; hash = "sha256-CutVTb7K4tjewq1xAjHEGUHFcuuP/Z4FFtj4xQb4zKQ="; </del> <ins> name = "0006-Hardening-Qt-code.patch"; url = "https://raw.githubusercontent.com/debian-calibre/calibre/debian/${version}-1/debian/patches/0006-Hardening-Qt-code.patch"; hash = "sha256-9P1kGrQbWAWDzu5EUiQr7TiCPHRWUA8hxPpEvFpK20k="; </ins> }) ] ++ lib.optional (!unrarSupport) ./dont_build_unrar_plugin.patch;

Related discussion:
text: Package name: Latest released version: Current version on the unstable channel: Current version on the stable/release channel: Notify maintainers I attempted to update the version myself, but encountered an issue: Unfortunately, I don't have the time to investigate further at the moment. Therefore, I would appreciate it if someone else could take it from here. Note for maintainers: Please tag this issue in your PR.
I've updated the issue to reflect that the same error persists even with version .
Code change:
export NIX_IGNORE_LD_THROUGH_GCC=1 if [ "$system" = "i686-darwin" -o "$system" = "powerpc-darwin" -o "$system" = "x86_64-darwin" ]; then <ins> export NIX_ENFORCE_PURITY= </ins> export NIX_DONT_SET_RPATH=1 export NIX_NO_SELF_RPATH=1 dontFixLibtool=1

Related discussion:
text: Any expression on darwin which sets fails to build claiming that the C compiler cannot create executables. This is the same issue as , but it more serious than I thought, so I'm raising it as a separate issue. To reproduce just change anything to use on darwin, like the build.
I'm beginning to suspect executables built on 10.9 which don't use clangStdenv, but rather use the gcc 4.8.2 which Nix builds. I'm seeing frequent and consistent general protection faults (EXCI386GPFLT) from several different executables built in my Nix store. It's still possible these frequent GPT faults could be due to a faulty processor, so I'm waiting on delivery of a new desktop machine to do some comparison testing.
For future note: Those GPT faults were from a bad memory module in my machine. After fixing that module, I was able to rebuild all of my Nix packages using , and it succeeded as expected.
Code change:
, python3 , spirv-headers , spirv-tools <del> , argSpirv-tools ? null , argSpirv-headers ? null </del> }: <del> # glslang requires custom versions of spirv-tools and spirb-headers. # The exact versions are taken from: # https://github.com/KhronosGroup/glslang/blob/${version}/known_good.json let localSpirv-tools = if argSpirv-tools == null then spirv-tools.overrideAttrs (_: { src = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Tools"; rev = "b27b1afd12d05bf238ac7368bb49de73cd620a8e"; sha256 = "0v26ws6qx23jn4dcpsq6rqmdxgyxpl5pcvfm90wb3nz6iqbqx294"; }; }) else argSpirv-tools; localSpirv-headers = if argSpirv-headers == null then spirv-headers.overrideAttrs (_: { src = fetchFromGitHub { owner = "KhronosGroup"; repo = "SPIRV-Headers"; rev = "f027d53ded7e230e008d37c8b47ede7cd308e19d"; sha256 = "12gp2mqcar6jj57jw9isfr62yn72kmvdcl0zga4gvrlyfhnf582q"; }; }) else argSpirv-headers; in </del> stdenv.mkDerivation rec { pname = "glslang"; <del> version = "11.1.0"; </del> <ins> version = "1.2.198.0"; </ins> src = fetchFromGitHub { owner = "KhronosGroup"; repo = "glslang"; <del> rev = version; sha256 = "1j81pghy7whyr8ygk7lx6g6qph61rky7fkkc8xp87c7n695a48rw"; </del> <ins> rev = "sdk-${version}"; sha256 = "sha256-FRiqsfoyjUW2kbbphxcy0Hn0TLVaszatM/nnWBrchRY="; </ins> }; # These get set at all-packages, keep onto them for child drvs passthru = { <del> spirv-tools = localSpirv-tools; spirv-headers = localSpirv-headers; </del> <ins> spirv-tools = spirv-tools; spirv-headers = spirv-headers; </ins> }; nativeBuildInputs = [ cmake python3 bison jq ]; postPatch = '' <del> cp --no-preserve=mode -r "${localSpirv-tools.src}" External/spirv-tools ln -s "${localSpirv-headers.src}" External/spirv-tools/external/spirv-headers ''; # Ensure spirv-headers and spirv-tools match exactly to what is expected preConfigure = '' HEADERS_COMMIT=$(jq -r < known_good.json '.commits|map(select(.name=="spirv-tools/external/spirv-headers"))[0].commit') TOOLS_COMMIT=$(jq -r < known_good.json '.commits|map(select(.name=="spirv-tools"))[0].commit') if [ "$HEADERS_COMMIT" != "${localSpirv-headers.src.rev}" ] || [ "$TOOLS_COMMIT" != "${localSpirv-tools.src.rev}" ]; then echo "ERROR: spirv-tools commits do not match expected versions: expected tools at $TOOLS_COMMIT, headers at $HEADERS_COMMIT"; exit 1; fi </del> <ins> cp --no-preserve=mode -r "${spirv-tools.src}" External/spirv-tools ln -s "${spirv-headers.src}" External/spirv-tools/external/spirv-headers </ins> ''; meta = with lib; {

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:
}: let <del> llvmPackages = llvmPackages_13; </del> inherit (llvmPackages) stdenv; in stdenv.mkDerivation rec { pname = "odin";

Related discussion:
text: Steps to reproduce the behavior: odin If you run the resulting binary through you'll see this strange backtrace: I think it has to do with the version of the C++ standard library that is getting linked. Adding and to the and updating the file to explicitly link allows it to run without segfaulting. (But thats just a workaround I'm using). EDIT: During more testing with the built binary, it also doesn't use the correct linker, which can cause problems if you are linking with Objective-C code/frameworks (not sure if this is a problem with how Odin is packaged with nix, or if its a problem that the Odin devs need to solve). Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]: Note: Was fixed by
macOS Odin support is kinda scuffed anyway with any deviation from what's expected. do you have the code for your workaround somewhere? then i can see if i can patch it in
I'm using for my project. It doesn't have any switching based on OS, and my override probably isn't necessary either. Honestly, the is probably the only thing needed to stop the seg faulting.
updating to llvm17 is not a bad idea either
Code change:
fairymax = callPackage ../games/fairymax { }; ferium = callPackage ../games/ferium { <del> inherit (darwin.apple_sdk.frameworks) Security; </del> <ins> inherit (darwin.apple_sdk.frameworks) Security SystemConfiguration; </ins> }; fheroes2 = callPackage ../games/fheroes2 { };

Related discussion:
text: Steps to reproduce the behavior: ferium cc thanks! <!-- 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]:
Code change:
secure-local-storage = [ keyring ]; }; <del> # Tests require encrypted secrets, see # https://github.com/snowflakedb/snowflake-connector-python/tree/master/.github/workflows/parameters doCheck = false; </del> <ins> preCheck = '' export HOME=$(mktemp -d) ''; nativeCheckInputs = [ pytest-xdist pytestCheckHook ]; disabledTestPaths = [ # Tests require encrypted secrets, see # https://github.com/snowflakedb/snowflake-connector-python/tree/master/.github/workflows/parameters "test/extras/simple_select1.py" "test/integ" # error getting schema from stream, error code: 0, error info: Expected to # be able to read 19504 bytes for message body but got 19503 "test/unit/test_connection.py" "test/unit/test_cursor.py" "test/unit/test_error_arrow_stream.py" "test/unit/test_ocsp.py" "test/unit/test_retry_network.py" "test/unit/test_s3_util.py" ]; disabledTests = [ # Tests connect to the internet "test_status_when_num_of_chunks_is_zero" "test_test_socket_get_cert" ]; </ins> pythonImportsCheck = [ "snowflake"

Related discussion:
text: package lists and as dependencies but upstream uses instead. Steps to reproduce the behavior: dependencies of package it to the dependencies listed by upstream and should not be in the dependencies list, but should n/a <!-- 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]:
That's a bot.
Thank you for the quick turnaround!
Code change:
{ lib <ins> , stdenv </ins> , buildPythonPackage , fetchPypi , setuptools

Related discussion:
text: Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible- . Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems. You can use to analyze the differences in the output of the two builds. To view the build log of the build that produced the artifact in the binary cache: In the context of pip we previously deleted these files,
Code change:
<ins> { lib , stdenv , rustPlatform , fetchFromGitHub , SystemConfiguration , python3 }: rustPlatform.buildRustPackage rec { pname = "rustpython"; version = "unstable-2021-12-09"; src = fetchFromGitHub { owner = "RustPython"; repo = "RustPython"; rev = "db3b3127df34ff5dd569301aa36ed71ae5624e4e"; sha256 = "sha256-YwGfXs3A5L/18mHnnWubPU3Y8EI9uU3keJ2HJnnTwv0="; }; cargoHash = "sha256-T85kiPG80oZ4mwpb8Ag40wDHKx2Aens+gM7NGXan5lM="; # freeze the stdlib into the rustpython binary cargoBuildFlags = "--features=freeze-stdlib"; buildInputs = lib.optionals stdenv.isDarwin [ SystemConfiguration ]; checkInputs = [ python3 ]; meta = with lib; { description = "Python 3 interpreter in written Rust"; homepage = "https://rustpython.github.io"; license = licenses.mit; maintainers = with maintainers; [ prusnak ]; # TODO: Remove once nixpkgs uses newer SDKs that supports '*at' functions. # Probably macOS SDK 10.13 or later. Check the current version in # .../os-specific/darwin/apple-sdk/default.nix # # From the build logs: # # > Undefined symbols for architecture x86_64: "_utimensat" broken = stdenv.isDarwin && stdenv.isx86_64; }; } </ins>

Related discussion:
text: Project description A Python-3 (CPython = 3.9.0) Interpreter written in Rust Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin
I tried to package it here: but run into compilation failure:
Rustpython master builds just fine. PR in
Code change:
<ins> diff --git a/gnome-panel/gp-module-manager.c b/gnome-panel/gp-module-manager.c index 58447fd84..7af99de7d 100644 --- a/gnome-panel/gp-module-manager.c +++ b/gnome-panel/gp-module-manager.c @@ -49,8 +49,16 @@ load_modules (GpModuleManager *self) { GDir *dir; const gchar *name; +  const gchar *modules_dir; -  dir = g_dir_open (MODULESDIR, 0, NULL); +  modules_dir = g_getenv ("NIX_GNOME_PANEL_MODULESDIR"); + +  if (!modules_dir) { +    g_warning ("The NIX_GNOME_PANEL_MODULESDIR environment variable was not set, modules will not be loaded."); +    return; +  } + +  dir = g_dir_open (modules_dir, 0, NULL); if (!dir) return; @@ -63,7 +71,7 @@ load_modules (GpModuleManager *self) if (!g_str_has_suffix (name, ".so")) continue; -      path = g_build_filename (MODULESDIR, name, NULL); +      path = g_build_filename (modules_dir, name, NULL); module = gp_module_new_from_path (path); g_free (path); </ins>

Related discussion:
text: Panel applets are being picked up from environment variable in and a completely hardcoded path in . First, we will need to patch the latter manager to use an environment variable as well. Second, we will need to do something similar to what . Or better, create  derivation. Originally posted by in
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
I'd like to tackle this, do you have any pointers? We need to get it to pick up at least right?
Code change:
addDriverRunpath wrapGAppsHook3 cmake <del> glslang </del> nasm ninja pkg-config

Related discussion:
text: Steps to reproduce the behavior: cemu Adding and to buildInputs might fix it <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Code change:
src = fetchurl { url = "mirror://gnome/sources/libgee/${ver_maj}/${name}.tar.xz"; <del> sha256 = "16a34js81w9m2bw4qd8csm4pcgr3zq5z87867j4b8wfh6zwrxnaa"; </del> <ins> sha256 = "1fy24dr8imrjlmsqj1syn0gi139gba6hwk3j5vd6sr3pxniqnc11"; </ins> }; doCheck = true; patches = [ ./fix_introspection_paths.patch ]; <del> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ autoconf vala_0_32 glib gobjectIntrospection ]; </del> <ins> nativeBuildInputs = [ pkgconfig autoconf vala pkgconfig gobjectIntrospection ]; buildInputs = [ glib ]; </ins> meta = with stdenv.lib; { description = "Utility library providing GObject-based interfaces and classes for commonly used data structures";

Related discussion:
text: Geary and are . I suppose updating might remove its dependency on the insecure . (I think i remember having seen somewhere in an issue tracker that this dependency was removed in Geary source code, but i cannot find now where i saw it.)
By the way, I do not really understand these GTK and WebKitGTK issues and versions, but, just for reference, there is an open issue about previous versions of Geary using GTK2 instead of GTK3: .
In Geary 0.12 there are some fresh bugs (for example, ). It looks like version 0.12.1 is in the beginning of November.
Running shows gtk2 as a transitive dependency from webkitgtk (which depends on both GTK 2 and GTK 3) and gnome-themes-standard. I do not think the latter is necessary for GTK 3 applications since Adwaita is built into GTK 3.