jiebi/CodeConvo huggingface dataset:
Change:
webcord = callPackage ../by-name/we/webcord/package.nix { electron = electron_30; }; <ins> webcord-vencord = callPackage ../by-name/we/webcord-vencord/package.nix { electron = electron_29; }; </ins> webex = callPackage ../applications/networking/instant-messengers/webex { }; webmacs = libsForQt5.callPackage ../applications/networking/browsers/webmacs {

Discussion:
Under Wayland on Hyprland, trying to launch Webcord results in a frozen window and then a crash on startup. It doesn't matter if I launch using Ozone flags or not. Vanilla Discord package launches without issue. I did not test if Webcord launches under Xorg. Steps to reproduce the behavior: launcher or shell to launch Webcord it crash instead of starting properly. Webcord launches and works fine. I am using Hyprland's upstream flake. However, I don't see why that might be relevant, but it might be worth mentioning. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Please test with an alternative Wayland compositor, e.g., sway or river.
Unfortunately, same behavior on Sway.
Then it's safe to assume it's an electron problem. We may consider overriding the electron version. is webcord working for you two?
Works for me
I've never run into such an issue on sway. did you ensure to disable hyprland when testing sway? Also, can you try with to rule out any electron issues?
It's probably the vencord patch
Seems to be the vencord patch. Logs of are as follows, but unlike the app actually starts. Perhaps would help?
On nixos-unstable webcord-vencord launches on Xorg but does not have anything relating to vencord working on master everything works properly on Xorg
I updated to vencord 1.8.4. It's still not working. I'm running out of ideas on what the cause could be.
seems to be caused by and it's still broken on . I was able to prevent the segfault by using electron 29:
Change:
./services/misc/nix-ssh-serve.nix ./services/misc/novacomd.nix ./services/misc/nzbget.nix <ins> ./services/misc/nzbhydra2.nix </ins> ./services/misc/octoprint.nix ./services/misc/osrm.nix ./services/misc/packagekit.nix

Discussion:
Project description From GitHub: Metadata homepage URL: source URL: license: apache 2.0 platforms: All (Java project)
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 is still important to me.
I marked this as stale due to inactivity. &rarr;
This issue is not stale. There is a PR in progress.
Change:
sha256 = "48d9be622049d8363cda84125c45d18b89e0ab7d99be5a93c0246f375ebad344"; }; <ins> nativeBuildInputs = [ setuptools-scm ]; </ins> propagatedBuildInputs = [ numpy scipy

Discussion:
fails to build since The log produced is Build succeeds 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. --
Change:
<ins> { stdenv, lib, fetchFromGitHub, cmake }: stdenv.mkDerivation rec { pname = "cjson"; version = "1.7.14"; src = fetchFromGitHub { owner = "DaveGamble"; repo = "cJSON"; rev = "v${version}"; sha256 = "1a3i9ydl65dgwgmlg79n5q8qilmjkaakq56sam1w25zcrd8jy11q"; }; nativeBuildInputs = [ cmake ]; meta = with lib; { homepage = "https://github.com/DaveGamble/cJSON"; description = "Ultralightweight JSON parser in ANSI C"; license = licenses.mit; maintainers = [ maintainers.matthiasbeyer ]; platforms = platforms.unix; }; } </ins>

Discussion:
Project description cJSON aims to be the dumbest possible parser that you can get your job done with. It's a single file of C, and a single header file. This is a new for mosquitto 2.0.0. There is a possible name clash as there is already a Lua and a Python implementation which are using as part of their name. Metadata homepage URL: source URL: license: MIT and ASL 2.0 platforms: Unix, unsure about the the others
PR for mosquitto update to 2.0.0 -
Change:
description = "Utility that builds rust-generated WebAssembly package"; mainProgram = "wasm-pack"; homepage = "https://github.com/rustwasm/wasm-pack"; <del> license = with licenses; [ asl20 /* or */ mit ]; </del> <ins> license = with licenses; [ asl20 # or mit ]; </ins> maintainers = [ maintainers.dhkl ]; }; }

Discussion:
Package name: wasm-pack Latest released version: 0.13.0 <!-- Search your package here: --- Current version on the unstable channel: 0.12.1 Current version on the stable/release channel: 0.12.1 <!-- 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. I just tried to make a PR with the change, but I got when I tried to build (while compiling ), and used all of my RAM while running (it did not finish). I'm using a x86-64 machine with Debian.
I encountered that error too. After reading I tried this: That resulted in a new error log. I don't know what to do but I thought I'll leave it here in the case that I could be useful to someone else
Change:
# link in the CLI utils (map (util: "ln -s ${base}/bin/${util} $out/bin/${util}") utils) <ins> "runHook postInstall" </ins> ]) ) ; <ins> postInstall = '' mkdir -p $out/share ln -s ${base}/share/applications $out/share/applications ln -s ${base}/share/icons $out/share/icons ln -s ${base}/share/mime $out/share/mime ''; </ins> # can't run this for each pname # stable and unstable are in the same versions.nix # and kicad-small reuses stable

Discussion:
Describe the bug is missing a menu entry to launch the application. To Reproduce Steps to reproduce the behavior: Expected behavior There should be a menu entry to launch the application. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata
see (probably shouldn't have been closed)
Change:
hash = "sha256-fZ2bPPjBK/H2jMI4S3EhvWJaNl4tK7HstxcHSAkoFW4="; }; <ins> patches = [ (fetchpatch { name = "0001-adapt-test-to-latest-mypy.patch"; url = "https://github.com/python-lsp/pylsp-mypy/commit/99cf687798464f810b128881dbbec82aa5353e04.patch"; sha256 = "sha256-wLaGMaW/gTab2fX7zGnemLQQNDWxBURYb7VsgEas61Y="; }) ]; </ins> propagatedBuildInputs = [ mypy python-lsp-server

Discussion:
Steps to reproduce the behavior: Please run and paste the result.
It seems that it is caused by this recent change in :
EDIT: the commit mentioned above is not the problem but the fix. Indeed, updates the test to work with the new version of mypy (0.991). The author has not made a new release yet. Hence, we have two choices: 1) Disable (temporarily) the tests waiting for the new release of . 2) Change the and fetch the master branch of the .
Does that commit apply cleanly to the latest version if used as a patch? You can it into on the derivation if so
Change:
./linux-5.6.patch # source: https://gist.github.com/joanbm/5c640ac074d27fd1d82c74a5b67a1290 ./linux-5.9.patch <ins> # source: https://github.com/archlinux/svntogit-community/blob/5ec5b248976f84fcd7e3d7fae49ee91289912d12/trunk/012-linux517.patch ./linux-5.17.patch </ins> ./null-pointer-fix.patch ./gcc.patch ];

Discussion:
fails to build when I tried to execute . Steps to reproduce the behavior: should build successfully. ! There are no maintainers for anymore, so I'll instead mention the last contributors.
Sorry but I no longer have a machine that uses that driver, but it looks like it's broken with linux 5.17. Here is the patch used by Arch:
Likewise I dont have a machine that runs this driver anymore
Same issue for me on 3 machines. The odd thing, the issue still remains after a temp fix of;
Can confirm that this is working with Will try to PR the patch.
Any idea when this issue will be resolved via the patch? I just failed to compile broadcom_sta when attempting to upgrade to kernel 5.17.1 on a Macbook Pro late 2013.
It's unlikely to happen anytime soon, since it looks like no one with merging permission has hardware that uses this driver. Maybe if has some time he could review it since he is already familiar with it, and it seems that the PR is just the patch used by Arch. In the meantime you can try and the made bye X9VoiD.
Change:
<del> { fetchurl, stdenv, python2Packages, makeWrapper, lib , xpdf, mesa, SDL, freeglut }: </del> <ins> { fetchurl, stdenv, python2, makeWrapper, lib , mesa, SDL, freeglut, ghostscript, pdftk, dejavu_fonts }: </ins> let <del> inherit (python2Packages) python pyopengl pygame setuptools pillow; </del> version = "0.11.1"; <ins> pythonEnv = python2.withPackages (ps: with ps; [pyopengl pygame pillow]); </ins> in stdenv.mkDerivation { # This project was formerly known as KeyJNote. <del> # See http://keyj.s2000.ws/?p=77 for details. </del> <ins> # See http://keyj.emphy.de/apple-lawsuit/ for details. </ins> name = "impressive-${version}";

Discussion:
System: 17.03beta320. (Gorilla) Nix version: nix-env (Nix) 1.11.7 Nixpkgs version: "17.03beta320." ; also occurs on master.
You need to install SDL-1.2: After installing SDL, you may need to recompile pygame.
This isn't how Nix works — libraries aren't installed.
Try the following steps - they worked for me on a fresh VirtualBox. Step 1: Add the following lines (taken from ) to : Step 2: Install the environment: Step 3: Load the environment: Step 4: Download a sample PDF: Step 5: Open the PDF in Impressive:
Yep, that works, thanks for the input! However, this should not be the only way it works — particularly because myEnvFun is deprecated in favour of nix-shell. I'll see if I can fix the packaging. EDIT: works. So it'll be because ctypes uses gcc to discover library paths, which is a little insane IMHO but hey. I'll add a step in the patchPhase which inserts the full path to the SDL library rather than using ctypes's discovery.
Change:
gox = callPackage ../development/tools/gox { }; <ins> goxlr-utility = callPackage ../tools/audio/goxlr-utility {}; </ins> gprolog = callPackage ../development/compilers/gprolog { }; gwe = callPackage ../tools/misc/gwe {

Discussion:
Project description An unofficial GoXLR App replacement for Linux, Windows and MacOS. Metadata homepage URL: source URL: license: MIT platforms: linux
Moving conversation back here to avoid spamming goxlr-utility maintainers :sweat_smile: I made a draft PR that you can find from It's closer to what the official .deb and .rpm packaging is doing, i.e. including some of the relevant resources, shell completion etc. I wouldn't mind adding you as a maintainer but to do that it probably requires adding you to the maintainer list as well. Should be easy to fix if you want to add PR to the branch.
Hey wow you are fast :D Yes, you can add me as a maintainer for this package. But as I understand it, I need to add me to the maintainer list first, right?
Hah, had some free time during the night and since I wanted to get my GoXLR setup working anyways thought I might as well sort this out. For the question: Yup, the requires to be on . The file itself lists the mandatory/optional fields in the metadata, but basically "a name and at least one contact/identity information" (e.g. a github id). Oh, and the list needs to stay in alphabetical order ^^ Feel free to make PR against this branch, I'll merge it as soon as I notice the PR :)
Added the module to the PR as well. I guess it might be hard to wait for someone with GoXLR to come in and review the PR (though I'd prefer someone to check that it doesn't violate any major guidelines) so if you don't mind I think it's possible for you to try it out and do a PR review, which likely speeds up the process at least :)
Managed to get the PR reviewed and should now be code-wise idiomatic enough to pass. I think based on the main thing remaining is getting thumbs up from you functionality-wise so that's it's not only "works on my machine" :sweat_smile:
I saw your PR and tried using nixpkgs-review to download it to my local machine and try to run it. I used these steps: Do you know if my approach is wrong? This is the first time I've tried a Nix PR. Unfortunately, I haven't found much information about it.

EDIT: Got it working
Glad to hear you got it working! :) The nixpkgs-review tool seems nice, hadn't used it myself but for building the PR it seems to do exactly what one would expect. I guess in this case there's a limit what it can do though as the udev rules are being on the module side and it probably doesn't handle that so some manual work is required :shrug: But again, all is good since you did manage to test the build!
Change:
}: let <del> version = "1.7.0"; </del> <ins> version = "1.9.0"; </ins> src = fetchFromGitHub { owner = "mealie-recipes"; repo = "mealie"; rev = "v${version}"; <del> hash = "sha256-z7kLBDzvzPWY7XmpROMpw3LcDpsl+hA+w1SdhrD/yNU="; </del> <ins> hash = "sha256-gg7ClclBS9j9n4/3HLxbX8HXTz9Zw5+BYG2MEYRsRBU="; </ins> }; frontend = callPackage (import ./mealie-frontend.nix src version) { };

Discussion:
Package name: Latest released version: 1.9.0 Current version on the unstable channel: 1.7.0 Current version on the stable/release channel: 1.2.0 Notify maintainers Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ stdenv, fetchFromGitHub, autoreconfHook <del> , pkgconfig, libuuid, e2fsprogs </del> <ins> , pkgconfig, libuuid, e2fsprogs, nilfs-utils, ntfs3g </ins> }: stdenv.mkDerivation rec {

Discussion:
As it stands, the package does not provide support for cloning filesystems; The symbolic links are missing. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Change:
ln -s ${daemon} $out/daemon ''; <ins> dontWrapGApps = true; </ins> nativeBuildInputs = [ <ins> wrapGAppsHook </ins> wrapQtAppsHook pkg-config cmake

Discussion:
The Jami client crashes with this error: Steps to reproduce the behavior: Jami via Jami: crashes with error. The Jami client should load as expected. Found references to how to make this work, unsure which if any are workable approaches: Error log: Please run and paste the result.
Same error on KDE Plasma:
I can't reproduce the problem on GNOME. Not sure how I can test it.
Maybe a virtual machine? LXQT is one of the installer options so setting up a VM should be straightforward.
to get rid of gtk impurities in the env you can fix by wrapping with the gtk wrapper, see the qt app example
will you submit a PR?
Change:
# pkgs.vimPlugins.nvim-treesitter.withAllGrammars withPlugins = f: self.nvim-treesitter.overrideAttrs { <del> passthru.dependencies = let grammars = map grammarToPlugin (f (tree-sitter.builtGrammars // builtGrammars)); copyGrammar = grammar: let name = lib.last (lib.splitString "-" grammar.name); in "ln -sf ${grammar}/parser/${name}.so $out/parser/${name}.so"; in [ (runCommand "vimplugin-treesitter-grammars" { meta.platforms = lib.platforms.all; } '' mkdir -p $out/parser ${lib.concatMapStringsSep "n" copyGrammar grammars} '') ]; </del> <ins> passthru.dependencies = map grammarToPlugin (f (tree-sitter.builtGrammars // builtGrammars)); </ins> }; withAllGrammars = withPlugins (_: allGrammars);

Discussion:
I noticed that nvim wasn't loading any of my treesitter plugins. I decided to check the plugin directory. hm. something is very wrong here. it isn't pulling in any grammars. let's investigate: ok, so it's looking for a file at . what does the grammar derivation look like? So the parser is ending up at instead of . What does the grammar derivation's source look like? Checking , this code has been in place for years. Checking for , I find It was merged three weeks ago. I see that is open. I couldn't find any information on this problem with GitHub search... Could that PR be merged quicker please? My editor setup is broken now :( system: host os: multi-user?: sandbox: version: nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I think this is not actually the direct cause of the issue you're seeing since the grammars go through (see the below, which precisely corrects the observed discrepancy) You're not seeing the grammars when you because the grammars are in . I explain how to properly build it in The PR is broken, don't get me wrong, but I think not this directly :p. For why your is broken, see I think it's because of your dependency on and which pulls in a without any grammars but I'm not sure. You can try giving an approval, I'm in the same boat as you (I don't have merge permissions). Apologies for breaking your setup!
Change:
<del> { lib, stdenv, fetchurl, fetchpatch </del> <ins> { lib, stdenv, fetchurl </ins> # native deps. , runCommand, pkg-config, meson, ninja, makeWrapper # build+runtime deps.

Discussion:
However, the following input is is rejected as "*: incorrect address specification": I expected kresd to listen on fe80::1 on port 53 on the ofborg interface, as the documentation suggests should be possible. I don't mind that it is impossible, but the documentation for this option isn't correct anymore. nixos-unstable-small, rev
Well, it no longer uses systemd sockets anymore, and instead there are a few in-nix regexps that convert them. It might not be perfect. Either way, the interface spec should surely be part of the IPv6 already, i.e. &ndash; and I think that should work (the generated lua config looks OK).
Ah, I see that systemd is weird here, at least in docs. So I don't know what we'll do with it. Either shuffle it in the in-nix regexps or document as a deviation, I suppose.
Change:
<ins> diff -ruN a/libtiff/CMakeLists.txt b/libtiff/CMakeLists.txt --- a/libtiff/CMakeLists.txt	2019-05-31 13:05:22.849705817 +0000 +++ b/libtiff/CMakeLists.txt	2020-11-27 21:50:03.527831837 +0000 @@ -42,6 +42,9 @@ libtiffxx.map) set(tiff_HEADERS +  tiffiop.h +  ${CMAKE_CURRENT_BINARY_DIR}/tif_config.h +  tif_dir.h tiff.h tiffio.h tiffvers.h) </ins>

Discussion:
Describe the bug I am trying to build for . is one giving me difficulty. Originally I filed an issue on : But the issue is instead with the libpng inside freeimage: Basically, libpng applies an incorrect ARM optimization to aarch64 that isn't actually available. From briefly looking at in nixpkgs, it seems that we patch with patches (and skimming that, it looks like it has a relevant aarch64 patch). So, my goal is to patch the vendored inside FreeImage, similar to how we patch itself. So far I've not had luck. I've tried with both the CRLF and LF patches from the 'apng' project and the regular patch used from the 'libpng-apng' project that is used in nixpkg's libpng. They all fail to apply and some complain about line endings, regardless of if I pipe the patch through dos2unix (or unix2dos) or not.
I seem to have fixed this by patching libpng inside of the freeimage source using the same patch as the derivation.. I'm just debating whether or not to allow it to be toggle-able as it is in the libpng derivation.
Hello, I'm a bot and I thank you in the name of the community for opening this issue. To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human. The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it. If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use or on the relevant files to find them. Lastly, you can always ask for help at or at .
still important to me
I marked this as stale due to inactivity. &rarr;
still important to me
You can close this I think
Change:
librest = callPackage ../development/libraries/librest { }; <del> libwebsockets = callPackage ../development/libraries/libwebsockets { }; </del> <ins> inherit (callPackages ../development/libraries/libwebsockets { }) libwebsockets_3_1 libwebsockets_3_2 libwebsockets; </ins> lidarr = callPackage ../servers/lidarr { };

Discussion:
libwebsockets 3.2.0 changed its behaviour in a way that breaks all versions of Mosquitto that use websockets, resulting in incoming connections being intermittent and very slow. It is fixed in their repository and will be in the next release presumably, but for now 3.2.0 is no good. If Mosquitto is the only other package using libwebsockets, I would suggest downgrading to 3.1.0, which behaves fine. Mosquitto 1.6.5, which should be released today, will refuse to compile with libwebsockets 3.2.0.
cc
mosquitto 1.6.5 fixes it - just haven't packaged it yet.
Mosquitto 1.6.5 does not fix this. There is a changelog entry which was written prior to this issue that is probably why you think it does have the fix. Sorry about that, I changed the changelog on the website post but not in the repo. The only fix for this is in libwebsockets itself.
it's pretty awesome having upstream providing proactive updates like this - much appreciated!
Change:
model-bakery = callPackage ../development/python-modules/model-bakery { }; <ins> model-checker = callPackage ../development/python-modules/model-checker { }; </ins> modelcif = callPackage ../development/python-modules/modelcif { }; modeled = callPackage ../development/python-modules/modeled { };

Discussion:
Project description A hyperintensional theorem prover for counterfactual conditionals and modal operators. Metadata homepage URL: source URL: license: mit platforms: unix, linux, darwin, ... Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> { lib, stdenv, pkg-config, fetchFromGitHub, python3, bash, vala_0_48 , dockbarx, gtk2, xfce, pythonPackages, wafHook }: </del> <ins> { lib , stdenv , fetchFromGitHub , bash , dockbarx , gobject-introspection , keybinder3 , pkg-config , python3Packages , vala_0_48 , wafHook , wrapGAppsHook , xfce }: </ins> stdenv.mkDerivation rec { pname = "xfce4-dockbarx-plugin"; version = "${ver}-${rev}"; ver = "0.6"; <del> rev = "5213876"; </del> <ins> rev = "5213876151f1836f044e9902a22d1e682144c1e0"; </ins> src = fetchFromGitHub { owner = "xuzhen";

Discussion:
Describe the bug xfce-dockbarx plugin fails to work due to missing library 'gi'; it shows nothing insdide the xfce panel. To Reproduce Steps to reproduce the behavior: xfce installed xfce.xfce4-dockbarx-plugin and dockbarx installed add dockbarx to the panel of XFCE the xfce panel 4-panel to show the error Expected behavior dockbarx shows up on the menu, with no errors in the terminal, with a taskbar in the panel Additional context Terminal output: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(james): nixpkgs: Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there: