jiebi/CodeConvo huggingface dataset:
Change:
extraConfig.console.keyMap = "de"; extraConfig.services.xserver.layout = "de"; }; <ins> custom = { tests = { us.qwerty = [ "a" "b" "g" "d" "z" "shift-2" "shift-3" ]; us.expect = [ "a" "b" "g" "d" "z" "@" "#" ]; greek.qwerty = map (x: "alt_r-${x}") [ "a" "b" "g" "d" "z" ]; greek.expect = [ "α" "β" "γ" "δ" "ζ" ]; }; extraConfig.console.useXkbConfig = true; extraConfig.services.xserver.layout = "us-greek"; extraConfig.services.xserver.extraLayouts.us-greek = { description = "US layout with alt-gr greek"; languages   = [ "eng" ]; symbolsFile = pkgs.writeText "us-greek" '' xkb_symbols "us-greek" { include "us(basic)" include "level3(ralt_switch)" key <LatA> { [ a, A, Greek_alpha ] }; key <LatB> { [ b, B, Greek_beta  ] }; key <LatG> { [ g, G, Greek_gamma ] }; key <LatD> { [ d, D, Greek_delta ] }; key <LatZ> { [ z, Z, Greek_zeta  ] }; }; ''; }; }; </ins> }

Discussion:
I use the following listing in to install a custom keyboard layout: This refers to files in the following structure: This worked until recently (last updated a few months ago), but now fails to build: <details<summaryFull trace</summary</detailsCommenting out the line causes the same error but for . Adding in plausible files in the suggested places also doesn't fix the issue. Steps to reproduce the behavior: up the configuration as above. . The system successfully builds, and I have access to the custom layout. <!-- 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.
Sorry, I forgot to notify maintainers, but I think it's just
This breakage happened with with the update of as they have switched to the meson build system.
Thanks, that's really helpful! I suppose I'll revert to before that merge for now (though I'm finding it hard to find the list of good commit hashes). Do you know any other workarounds?
You can use . that does not have those changes. For a list you can look at in the "Input changes" column. That is a log of the "nixos-unstable" branch, for which the binary cache has been filled after a few tests have been run.
The script that patches the makefile to include the extra layouts need to be updated.
Can you test if your layouts work correctly with ? I a test for a basic file but I haven't tried other types.
Works fine for me but I also only use symbols
Fix merged, you can track the progress to nixos-unstable .
Change:
-H:Name=${pname}  -H:EnableURLProtocols=https,http  -H:+ReportExceptionStackTraces  <ins> ${lib.optionalString stdenv.isDarwin ''-H:-CheckToolchain''}  </ins> --report-unsupported-elements-at-runtime  --initialize-at-build-time  --no-fallback

Discussion:
Describe the bug When running I get the following error message: Looking at the executable the first line is: In fish does not return the name of the current executed file. It appear to work when running this using . Also as comparison look at the file generated via package manager: To Reproduce Steps to reproduce the behavior: Expected behavior should start the server Additional context So with . Notify maintainers Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(yogsototh): nixpkgs: Maintainer information:
Hey this version is pretty outdated, could you try latest which is using graalvm binary?
Also the brew forumla you saw is outdated as well, the updated is
You are probably using the stable channel 20.09 channel, that should explain why you're still using the with JVM instead of GraalVM compiled binary. Switch to the unstable channel instead. I am not sure if it will work though since this package was never tested with macOS (and the fact that this package is broken in Hydra: ).
I just tested with latest master commit And if failed to build: I think the main bug is probably fixed. This is just another one :). This is late for me. I'll probably give it a look another day. Thanks for checking!
I think all GraalVM's packages build with Clojure are broken in macOS simply by the lack of people that has macOS systems to test/fix them. If you can fix this, a PR would be welcome :slightlysmilingface: .
Agreed If you have mac, using the homebrew official clojure-lsp formula should work as well: https://clojure-
Change:
postgresqlBackupCron = db: '' <del> ${config.services.postgresqlBackup.period} root ${config.services.postgresql.package}/bin/pg_dump ${db} | ${gzip}/bin/gzip -c > ${location}/${db}.gz </del> <ins> ${config.services.postgresqlBackup.period} root ${config.services.postgresql.package}/bin/pg_dump ${db} -U postgres | ${gzip}/bin/gzip -c > ${location}/${db}.gz </ins> ''; in

Discussion:
I want to automatically back up a Postgresql database. However, using the option I get an empty backup file. One thing I recognized is that all postgre command line tools fail when run locally as root. Any attempt to map root automatically to the postgres master user was unsuccessful so far. All utilities require the option to work properly. For example fails with , while works. The nixos test () uses and thus succeeds. Note that this also affects the submodule of . The data base initialization script fails until you add to all the commands (or run it with ). Am I overlooking something in the postgre configuration? Or do the nixos modules need a patch? If the problem can be solved by adding the right options to the postgre this should be mentioned somewhere in the module description or the manual. I any case it is not good that the backup fails quietly. Please run and paste the results. system: host os: multi-user?: sandbox: version: channels(root): PostgreSQL 9.6.8
Change:
homepage = "http://www.quickfixengine.org"; license = licenses.free; # similar to BSD 4-clause maintainers = with maintainers; [ bhipple ]; <ins> broken = stdenv.isAarch64; </ins> }; }

Discussion:
Steps to reproduce the behavior: quickfix The package does not build on macos (darwin) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> diff --git a/ext/soup/gstsouploader.c b/ext/soup/gstsouploader.c index 85048ce303..d7d818cf95 100644 --- a/ext/soup/gstsouploader.c +++ b/ext/soup/gstsouploader.c @@ -181,7 +181,7 @@ gst_soup_load_library (void) GST_DEBUG ("LibSoup 2 found"); } else { GST_DEBUG ("Trying all libsoups"); -      libsoup_sonames[0] = LIBSOUP_3_SONAME; +      libsoup_sonames[0] = "@nixLibSoup3Path@/" LIBSOUP_3_SONAME; libsoup_sonames[1] = LIBSOUP_2_SONAME; } </ins>

Discussion:
According to the GStreamer website, the "good" plugins package should contain the "soup" plugin. However, the nix package does not. Steps to reproduce the behavior: packages and Result: nothing found. As a result, cannot play any streams, failing with "could not create souphttpsrc element". should include . : : Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
please try and see if that fixes the problem for radiotray-ng
This fixes the problem for , thanks. Does this mean that is OK?
not really, in my opinion as it doesn't work out of the box. there was a PR to partially fix gstreamer but seems like it was missing glib-networking and didn't want to add it for some reason and was abandoned. if the gstreamer pkg isn't modified then adding glib-networking and libsoup to the ldlibrarypath is a work around.
The issue title is misleading. The loading of the library is broken but gst-plugins-good is actually compiled against libsoup.
Change:
buildPythonPackage rec { pname = "langchain-core"; <del> version = "0.1.43"; </del> <ins> version = "0.1.44"; </ins> pyproject = true; disabled = pythonOlder "3.8";

Discussion:
In this was to the list of . As is linux-only this breaks the build for and all of it's dependencies on other platforms such as The package also seems to build without this dependency (at least on ) -- I hope I didn't overlook something here (also sadly can't check right now). Thank you! Steps to reproduce the behavior: or 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]:
Change:
--prefix XDG_DATA_DIRS : "${gnome_themes_standard}/share:$out/share:$XDG_ICON_DIRS"  --suffix XDG_DATA_DIRS : "$GSETTINGS_SCHEMAS_PATH" <ins> wrapProgram "$out/bin/gnome-shell-extension-tool"  --prefix PYTHONPATH : "${python3Packages.pygobject3}/lib/python3.4/site-packages:$PYTHONPATH" </ins> wrapProgram "$out/libexec/gnome-shell-calendar-server"  --prefix XDG_DATA_DIRS : "${evolution_data_server}/share:$out/share:$XDG_ICON_DIRS:$GSETTINGS_SCHEMAS_PATH"

Discussion:
System: NixOS: (Flounder) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version:
Change:
rustPlatform.buildRustPackage rec { pname = "sequoia-sq"; <del> version = "0.34.0"; </del> <ins> version = "0.37.0"; </ins> src = fetchFromGitLab { owner = "sequoia-pgp"; repo = "sequoia-sq"; rev = "v${version}"; <del> hash = "sha256-voFektWZnkmIQzI7s5nKzVVWQtEhzk2GKtxX926RtxU="; </del> <ins> hash = "sha256-D22ECJvbGbnyvusWXfU5F1aLF/ETuMyhAStT5HPWR2U="; </ins> }; <del> patches = [ # Fixes test failing on Darwin, see: # https://gitlab.com/sequoia-pgp/sequoia-sq/-/issues/211 (fetchpatch { url = "https://gitlab.com/sequoia-pgp/sequoia-sq/-/commit/21221a935e0d058ed269ae6c8f45c5fa7ea0d598.patch"; hash = "sha256-ZjTl3EumeFwMJUl+qMpX+P2maYz4Ow/Tn9KwYbHDbes="; }) ]; cargoHash = "sha256-3ncBpRi0v6g6wwPkSASDwt0d8cOOAUv9BwZaYvnif1U="; </del> <ins> cargoHash = "sha256-jFpqZKyRCMkMtOezsYJy3Fy1WXUPyn709wZxuwKlSYI="; </ins> nativeBuildInputs = [ pkg-config

Discussion:
Steps to reproduce the behavior: Observed: Full checkPhase log (copied from Garnix): 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. --- system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The checkPhase still fails with this PR applied, but it is a different error: Error: While creating /homeless- Caused by: Permission denied (os error 13)
Thanks for the report (I thought I rebuilt it successfully before I opened the PR). Now should be ready now (the failing test is skipped, and an upstream issue was created).
Change:
<ins> { lib , stdenv , fetchFromGitHub , meson , ninja , python3 }: stdenv.mkDerivation rec { pname = "libvarlink"; version = "22"; src = fetchFromGitHub { owner = "varlink"; repo = pname; rev = version; sha256 = "1i15227vlc9k4276r833ndhxrcys9305pf6dga1j0alx2vj85yz2"; }; nativeBuildInputs = [ meson ninja ]; postPatch = '' substituteInPlace varlink-wrapper.py  --replace "/usr/bin/env python3" "${python3}/bin/python3" # test-object: ../lib/test-object.c:129: main: Assertion `setlocale(LC_NUMERIC, "de_DE.UTF-8") != 0' failed. # PR that added it https://github.com/varlink/libvarlink/pull/27 substituteInPlace lib/test-object.c  --replace 'assert(setlocale(LC_NUMERIC, "de_DE.UTF-8") != 0);' "" patchShebangs lib/test-symbols.sh ''; doCheck = true; meta = with lib; { description = "C implementation of the Varlink protocol and command line tool"; homepage = "https://github.com/varlink/libvarlink"; license = licenses.asl20; maintainers = with maintainers; [ artturin ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description Kanshi uses it now, by default, it'd be good if we had it in nixpkgs. Metadata homepage URL: source URL: license: APL2 platforms: linux (??)
Change:
pytestCheckHook ]; <del> env.EINOPS_TEST_BACKENDS = "numpy,chainer"; </del> <ins> env.EINOPS_TEST_BACKENDS = "numpy"; </ins> preCheck = '' export HOME=$(mktemp -d);

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . maintainers cc: python311Packages.chainer maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: -
fixed in master
Change:
httm = callPackage ../tools/filesystems/httm { }; <ins> jobber = callPackage ../tools/system/jobber {}; </ins> kanata = callPackage ../tools/system/kanata { }; kanata-with-cmd = kanata.override { withCmd = true; };

Discussion:
Project description Jobber is a "modern" replacement for cron, with sophisticated status-reporting and error-handling, and simpler configuration. Metadata homepage URL: source URL: license: mit platforms: "Unix-like systems"
So this would also require a module I assume.
In a certain sense the module can be delegated for later.
I marked this as stale due to inactivity. &rarr;
I'd like this! I've never contributed to Nixpkgs before... so I might be able to do this
Go for it, man!
Change:
mold = callPackage ../development/tools/mold { }; <ins> mold-wrapped = wrapBintoolsWith { bintools = mold; extraBuildCommands = '' wrap ${targetPackages.stdenv.cc.bintools.targetPrefix}ld.mold ${../build-support/bintools-wrapper/ld-wrapper.sh} ${mold}/bin/ld.mold wrap ${targetPackages.stdenv.cc.bintools.targetPrefix}mold ${../build-support/bintools-wrapper/ld-wrapper.sh} ${mold}/bin/mold ''; }; </ins> mommy = callPackage ../tools/misc/mommy { }; moon = callPackage ../development/tools/build-managers/moon/default.nix { };

Discussion:
is a fast and multi threaded modern linker. We already have it in Nixpkgs, however, unlike , it has not been wrapped in a package so that it can find the libraries to dynamically link against. Hence, dynamic linking in in NixOS fails. This issue is created so that we can wrap mold inside a shell script, like what happens to when it is installed through or even normal . I would be open to helping port such a script for .
I have tried simply replacing the executable with in the wrapper script, but it didn't seem to work. I am not very familiar with how this script works or what I am missing For more information, see
After some discussion on Matrix (thanks !), I was able to get mold working in a dev shell by using the following snippet: Is there any way we can just expose this as a wrapped mold in Nixpkgs so we don't have to add this to every shell we need mold in?
Is this relevant anymore? In addition to , we also have now. Here's a test we have for it in :
Further work is to rename to so users have to choose explicitly
Change:
fetchFromGitHub { owner = "CodeDownIO"; repo = "General"; <del> rev = "baf9e22ecdf97b6424a611ac4a565c6ee60d3f44"; sha256 = "1nd3x2z8r6578149pbpkx9qw2ajln1kfy7w5kjsnv56v180h0ddf"; # date = "2023-12-14T12:20:00+00:00"; </del> <ins> rev = "de80ad56e87f222ca6a7a517c69039d35437ab42"; sha256 = "0pz1jmmcb2vn854w8w0zlpnihi470649cd8djh1wzgq2i2fy83bl"; # date = "2023-12-22T03:28:12+00:00"; </ins> }

Discussion:
Steps to reproduce the behavior: to create a Julia environment with The issue appears to originate from a missing hash within a dependency. However, the root cause of this problem remains uncertain to me. Building a Julia environment with other packages like and does work flawlessly. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for the report! I'll take a look.
Change:
pytest ]; <ins> # test_string__month_day_hour_minute_second fails on darwin </ins> checkPhase = '' <del> pytest tests </del> <ins> LC_ALL=en_US.utf8 pytest tests  --deselect=tests/client_test/ttypes_test.py::TestTimestamp::test_string__month_day_hour_minute_second </ins> ''; meta = with lib; {

Discussion:
Describe the bug I tried adding stig to my package list and then updating in order to install it. It does not build successfully. To Reproduce Steps to reproduce the behavior: install (I used home-manager if it matters, but just as a package list, I don't config with it) Expected behavior I expected the build to succeed Additional context This is a remote client for Transmission that I wanted to try. I am on NixOS unstable. Metadata Please run and paste the result. Maintainer information:
Change:
rm -rf $out/lib ''} <ins> ${lib.optionalString (lib.versionAtLeast version "12.0") '' rm $out/host-linux-x64/libQt6* ''} </ins> # Remove some cruft. ${lib.optionalString ((lib.versionAtLeast version "7.0") && (lib.versionOlder version "10.1")) "rm $out/bin/uninstall*"}

Discussion:
Some cuda packages come with vendored copies of libraries that are already available in nixpkgs. These vendored libraries still require patching their Runpaths, their presence reduces determinism, and breaks "deep replacement" (i.e. nixpkgs' feature allowing to ensure that everything in a package set uses the same revision of a dependency). For instance, ships , which otherwise is available as: Cf. Tasks [ ] Look into deleting these vendored libraries and re-linking their reverse dependencies against nixpkgs alternatives
Change:
}; nativeBuildInputs = [ <del> pkg-config intltool wrapGAppsHook </del> <ins> autoreconfHook intltool pkg-config wrapGAppsHook </ins> ]; buildInputs = [ <del> xorg.libX11 xorg.libXtst pcre gst_all_1.gstreamer glib xosd xorg.libXext xorg.libXi libnotify enchant gdk-pixbuf gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good </del> <ins> enchant gdk-pixbuf glib gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good gst_all_1.gstreamer libnotify pcre xorg.libX11 xorg.libXext xorg.libXi xorg.libXtst xosd </ins> ]; patches = [

Discussion:
Enchant 2 (now the default) is long supported by most packages. The following packages need to be updated or removed: [x] gtkspell2 (dead): [x] xiphos: [x] subtitleeditor: [x] xneur: (contains the removal of enchant1) [x] gnome2.gtkhtml (dead): [x] gnome2.gtkhtml4 (dead): [x] gnome.gtkhtml (dead?): [x] php.extensions.enchant:
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 .
This issue is still relevant.
the list from is not up-to-date. e.g. is already fixed maybe we can also close it, because defaults to version 2 and to version 1.
I marked this as stale due to inactivity. &rarr;
Updated the list.
Now with xiphos merged You can thick both xiphos and gnome2.gtkhtml4 off the checklist
Pushed the enchant1 removal commit to
Change:
lib, fetchurl, }: appimageTools.wrapType2 rec { pname = "httpie-desktop"; version = "2024.1.2";

Discussion:
No desktop file is installed when installing httpie-desktop. Steps to reproduce the behavior: httpie-desktop. find it in the application list of GNOME. Find it in the application list of GNOME. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --- system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
touch "./install.lock" # Clang-format from nix package. <del> mv ./LLVM/ ./LLVM_orig </del> <ins> rm -rf ./LLVM </ins> mkdir "./LLVM/" find "${clang-tools}" -mindepth 1 -maxdepth 1 | xargs ln -s -t "./LLVM" # Patching binaries <del> chmod +x bin/cpptools bin/cpptools-srv bin/cpptools-wordexp debugAdapters/bin/OpenDebugAD7 </del> <ins> chmod +x bin/cpptools bin/cpptools-srv bin/cpptools-wordexp bin/libc.so debugAdapters/bin/OpenDebugAD7 </ins> patchelf --replace-needed liblttng-ust.so.0 liblttng-ust.so.1 ./debugAdapters/bin/libcoreclrtraceptprovider.so ''; <del> postFixup = lib.optionalString gdbUseFixed '' wrapProgram $out/share/vscode/extensions/ms-vscode.cpptools/debugAdapters/bin/OpenDebugAD7 --prefix PATH : ${lib.makeBinPath [ gdb ]} ''; </del> <ins> postFixup = '' autoPatchelf $out/share/vscode/extensions/ms-vscode.cpptools/debugAdapters # cpptools* are distributed by the extension and need to be run through the distributed musl interpretter patchelf --set-interpreter $out/share/vscode/extensions/ms-vscode.cpptools/bin/libc.so $out/share/vscode/extensions/ms-vscode.cpptools/bin/cpptools patchelf --set-interpreter $out/share/vscode/extensions/ms-vscode.cpptools/bin/libc.so $out/share/vscode/extensions/ms-vscode.cpptools/bin/cpptools-srv patchelf --set-interpreter $out/share/vscode/extensions/ms-vscode.cpptools/bin/libc.so $out/share/vscode/extensions/ms-vscode.cpptools/bin/cpptools-wordexp '' + lib.optionalString gdbUseFixed '' wrapProgram $out/share/vscode/extensions/ms-vscode.cpptools/debugAdapters/bin/OpenDebugAD7 --prefix PATH : ${lib.makeBinPath [ gdb ]} ''; </ins> meta = { description = "The C/C++ extension adds language support for C/C++ to Visual Studio Code, including features such as IntelliSense and debugging.";

Discussion:
Open a C++ project in vscode with the extension installed and see the following in the Extension Host output window: Steps to reproduce the behavior: a C++ project in vscode with the extension installed how autocompletion etc. features do not activate. to the output window and select the Extension Host and you will see the following: The extension should work ! Add any other context about the problem here. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm wondering if that should be 0555 instead of 0444.
Adding to got me around this particular issue but now I'm running into which should be resolved by moving to 1.20.5
Moving to 1.20.5 doesn't fix the startup issue
I'm replying to your comment here I can reproduce this with the following: Attached is the flake I end up with. My system packages are the following:
After changing the permission of this is what I get: If instead I run through manually I make some progress (it's looking for in my home directory) and it exits.
This is most likely
Change:
faac ] ++ optionals stdenv.isLinux [ bluez <ins> libva # vaapi requires libva -> libdrm -> libpciaccess, which is Linux-only in nixpkgs </ins> wayland wayland-protocols ] ++ optionals (!stdenv.isDarwin) [

Discussion:
Describe the bug Building gst-plugins-bad-1.18.0 errors out on Darwin with: To Reproduce On master: Expected behavior should compile Additional context Version bump from 1.16.2 -1.18.0 in includes new dependencies libmicrodns and libva that might be incompatible for macOS Notify maintainers Metadata
has tags on the right so chances are that isn't true and that it works on Darwin. Could you try in there?
leads to continuing down this rabbit hole leads to libpciaccess is pulled in by libdrm, which is pulled in by libva, which is pulled in by gst-plugins-bad as mentioned above. Since the cited attribute is in I don't suppose it is feasible for Darwin.
Thanks, I hadn't found that override, that's what I needed to know. This might fix it, give it a try: PR
build continues as expected, yet leads to
gist of meson-
Probably needs in on Darwin, looking at:
so disabling v4l2codecs solved the problem. Complete diff:
just noticed your comment. Yes, indeed, that was the last piece. Thx.
Change:
pythonRelaxDeps = [ # platformdirs 4.x is backwards compatible; https://github.com/python-poetry/poetry/commit/eb80d10846f7336b0b2a66ce2964e72dffee9a1c "platformdirs" <ins> # xattr 1.0 is backwards compatible modulo dropping Python 2 support: https://github.com/xattr/xattr/compare/v0.10.0...v1.0.0 "xattr" </ins> ]; propagatedBuildInputs = [

Discussion:
Steps to reproduce the behavior: on x86_64-darwin Broken commit: Working commit: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Here, aarch64-darwin has the same problem.
Same on .
Ah apparently already fixed on