jiebi/CodeConvo huggingface dataset:
Change:
}; cargoDeps = rustPlatform.fetchCargoTarball { <del> inherit (finalAttrs) src sourceRoot version; </del> <ins> inherit (finalAttrs) patches src sourceRoot version; </ins> name = "${finalAttrs.pname}-${finalAttrs.version}"; <del> hash = "sha256-uE4r0smgSbl4l77/MsHtn1Ar5fqspsYcLC/u8TUrcu8="; </del> <ins> hash = "sha256-LtQS0kH+2P4odV7BJYiH6T51+iZHAM9W9mV96rNfNWs="; </ins> }; nativeBuildInputs = [ cargo <del> cargo-tauri </del> <ins> cargo-tauri_2 gobject-introspection </ins> makeBinaryWrapper pkg-config rustc rustPlatform.cargoSetupHook ]; <del> buildInputs = [ cairo gdk-pixbuf gobject-introspection libsoup openssl pango webkitgtk ]; </del> <ins> buildInputs = [ cairo gdk-pixbuf libsoup_3 openssl pango webkitgtk_4_1 ]; </ins> env = { OPENSSL_NO_VENDOR = 1;

Discussion:
Steps to reproduce the behavior: Attempt to build surrealist version 2.0.6 on NixOS 24.11. The build fails during the build phase. I reported a similar issue here: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
another failure
Change:
StormLib = stormlib; # Added 2024-01-21 sumneko-lua-language-server = lua-language-server; # Added 2023-02-07 supertux-editor = throw "'supertux-editor' has been removed, as it was broken and unmaintained"; # Added 2023-12-22 <ins> swiProlog = lib.warn "swiProlog has been renamed to swi-prolog" swi-prolog; # Added 2024-09-07 swiPrologWithGui = lib.warn "swiPrologWithGui has been renamed to swi-prolog-gui" swi-prolog-gui; # Added 2024-09-07 </ins> swift-im = throw "swift-im has been removed as it is unmaintained and depends on deprecated Python 2 / Qt WebKit"; # Added 2023-01-06 swig1 = throw "swig1 has been removed as it is obsolete"; # Added 2024-08-23 swig2 = throw "swig2 has been removed as it is obsolete"; # Added 2024-08-23

Discussion:
It seems that errors with when attempting to have in . There has been no updates in the lspserver. I came across this while trying to update my systems. Currently, says , so that was the last build I had with the lsp not causing a build failure. Steps to reproduce the behavior: this expression: It seems this started happening in . Works fine on the parent commit. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
It seems adding to allows it to build, it is not clear to me how is being used here as I am not familiar with how packs work in swiProlog and why made this necessary. From looking at that commit in , it appears to be something that changed upstream. This builds:
I can confirm that with 9.1.21, swi-prolog + lsp-server builds just fine, even with the latest packaging. Something must indeed have changed upstream. 9.1.22 is the first version that stops building for me. The notes that the pack system got a refactor at that point, so that's probably what is going on here, but nothing indicates a sudden need for git. If git is now necessary for pack installation (even if we already pre-cloned everything) it should be a dependency. any idea why git became necessary here?
We can resolve this with a patch to SWI-Prolog to respect in the options, then adding that option to our invocation. I submitted a PR to SWI-Prolog (SWI-Prolog/swipl-devel). If upstream merges this, we can just apply the same patch to stable.
swi-prolog 9.2.7 backported the PR mentioned above. I've modified the package definition to supply the proper flag which suppresses git use during extraPacks install.
Change:
src = fetchFromGitHub { owner = "pappasam"; repo = pname; <del> rev = "c4c470cff67e54593a626b22d1b6b05e56fde3a3"; hash = "sha256-qFBni97B/GkabbznnZtWTG4dCHFkOx5UQjuevxq+Uvo="; </del> <ins> rev = "v${version}"; hash = "sha256-+k4WOoEbVe7mlPyPj0ttBM+kmjq8V739yHi36BDYK2U="; </ins> }; <del> pythonRelaxDeps = [ "pygls" ]; </del> nativeBuildInputs = [ poetry-core <del> pythonRelaxDepsHook </del> ]; propagatedBuildInputs = [

Discussion:
I have the build failure issue after one/some of today's commits with nixpkgs/master One of failed tests: textnSimple test function.ntextnSimple test function.n while original test does not contain this 'textn...n' multiline string Please run and paste the result.
Change:
, makeWrapper , xdg-utils , dbus <del> , qtbase , qtwebengine , qtx11extras , qtquickcontrols2 , qtgraphicaleffects </del> , getconf , glibc , libXrandr

Discussion:
Using teamviewer with I can not connect to remote hosts. The connection is established, but the window does not appear. If i try to connect to the same host again, I receive the message that I already have a connection open. TeamViewer is working as expected on EndeavourOS. Steps to reproduce the behavior: TeamViewer to any host for password appears for connected host does not appear to the same host again "you are already connected" appears the host computer it says that Im connected It seems like its the same bug as I also get the same errors in my log file <!-- 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]:
please try the linked PR and report back if this solved your issue. Thanks
I can confirm that it work!!! :partyingface: Thanks for the fast reply :)) However, I'm now getting a commercial use restriction ! I dont know if this has anything to do with nixpkgs or if its just because I tried to connect many times now. On the teamviewer website I have requested to remove my restriction lets see how it goes ;)
yay! I am pretty sure this is independent of NixOS. I had this in the past as well (independent of NixOS). I don't know how teamviewer tries to detect commercial use. But glad to here it works!
I would really like to learn more about packaging programs for nixpkgs so I can contribute more myself. Do you have any recommendations on how to learn the different options for mkDerivation, the different phases, wrapping programs and libraries, etc.? I feel like the documentation is basically non-existend. If anything comes to mind (including workshops, etc.) feel free to just send me an email (this issue is probably the wrong place to discuss this)
Hi awesome! I'm just gonna answer you here for anyone who is also interested: There is a handbook () which has a whole chapter about contributing to There is which helps a lot (just search for it or ask a question there) It helped me a lot to look at how other packages are packed.

Just clone and look at how similar services or programs are packaged There is a matrix Generally just start small. Find some nixpkgs which you'd like to see upgraded and update the version and hash and build it locally in your nixpkgs repo and submit a pull request ;-) If you still have trouble, just ask again on discourse (Im there, too) and we'll go from there :+1:
Change:
"-DCOMPILE_QML=ON" # see https://github.com/Nheko-Reborn/nheko/issues/389 ]; <ins> # https://github.com/NixOS/nixpkgs/issues/201254 NIX_LDFLAGS = lib.optionalString (stdenv.isLinux && stdenv.isAarch64 && stdenv.cc.isGNU) "-lgcc"; </ins> preFixup = lib.optionalString voipSupport '' # add gstreamer plugins path to the wrapper qtWrapperArgs+=(--prefix GST_PLUGIN_SYSTEM_PATH_1_0 : "$GST_PLUGIN_SYSTEM_PATH_1_0")

Discussion:
Steps to reproduce the behavior: i noticed the break after the nheko 0.10.2 -0.11.0 upgrade landed in nixos-unstable: hydra failure (click for the build log): build is currently broken in both master () and has been fixed in nixos-22.11, see for having initiated the backport. tagging as maintainer of both mtxclient and nheko. Please run and paste the result.
tested against the outstanding mtxclient 0.9.0 -0.9.1 PR: still broken.
I have no idea why a standard library would depend, let alone be missing, on a different architecture.
Likely due to us using outdated gcc (gcc9) on aarch64-linux. The story is complicated, but is being addressed.
Forcing it to use gcc11Stdenv may fix the issue.
It seems so: I tested by cross-compiling mtxclient (I don't have an aarch64 system).
Opened
Great... now coeurl fails to build. EDIT: Fixed, but nheko is still broken.
hope nobody minds this extra notification that is me thanking you all for jumping in so readily to fix things, even for someone you’ve never met. anyone reading this: what you’re doing here has more impact than you know.
Change:
, json-glib , elementary-dock , bamf <del> , switchboard </del> <ins> , switchboard-with-plugs </ins> , libunity , libsoup , wingpanel

Discussion:
Describe the bug Open indicator and see the following in journal The error at the top comes from now depending on settings schema (provided by ibus). This situation is annoyingly complex, because we cannot wrap . So what we try to do is create a wrapper with all the transitive dependencies of the plugins and call it day. We used to do patches to hardcode the gsettings, but this was far to much work to maintain and could be prone to developer error sometimes. I'm thinking the easiest solution would be to add all the transitive dependencies of to , and then wingpanel's can pick up all the proper dependencies. I think the only ideal request I could make to Pantheon upstream is to make use of SearchProviders from GNOME I believe this basically should be the very thing they want. They currently have a forked version of synapse's plugins system which IMHO appears to be inferior. To Reproduce Steps to reproduce the behavior: wingpanel-with-indicators the switchboard-plugin process get killed Expected behavior The switchboard-plugin process doesn't die. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
Change:
# Parse the command line. origArgs=("$@") <del> copyClosureFlags=() </del> <ins> copyFlags=() </ins> extraBuildFlags=() lockFlags=() flakeFlags=(--extra-experimental-features 'nix-command flakes')

Discussion:
says but in flake mode, it uses , not , and the flag has no effect. I guess this is technically as documented, but a bit surprising. Should it pass to as well?
Is there any workaround for now?
Change:
# enable dummy Demo Instrument (only if code is available) USE_DEMOINST = true ; <ins> # enable Video Test Patch Generator and 3DLUT device support # (V2.0.0 and above) USE_VTPGLUT = false ; # enable Printer device support USE_PRINTER = false ; # enable CMF Measurement device and accessory support (if present) USE_CMFM = false ; </ins> # Use ArgyllCMS version of libusb (deprecated - don't use) USE_LIBUSB = false ; <del> # For testing CCast DEFINES += CCTEST_PATTERN ; </del> <ins> # Compile in graph plotting code (Not fully implemented) USE_PLOT = true ;		# [true] </ins> JPEGLIB = ; JPEGINC = ;

Discussion:
<!-- 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 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: argyllcms <!-- The current version can be found easily with the same process than 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: 2.2.0 desired version: 2.2.1 last edited by testing it is only possible with gnome color manager setting, since displaycal is broken you also need special, expensive hardware
Change:
"/dev/shm" = { fsType = "tmpfs"; options = [ "nosuid" "nodev" "strictatime" "mode=1777" "size=${config.boot.devShmSize}" ]; }; "/dev/pts" = { fsType = "devpts"; options = [ "nosuid" "noexec" "mode=620" "ptmxmode=0666" "gid=${toString config.ids.gids.tty}" ]; }; <del> # To hold secrets that shouldn't be written to disk (generally used for NixOps, harmless elsewhere) "/run/keys" = { fsType = "ramfs"; options = [ "nosuid" "nodev" "mode=750" "gid=${toString config.ids.gids.keys}" ]; }; </del> <ins> # To hold secrets that shouldn't be written to disk "/run/keys" = { fsType = "ramfs"; options = [ "nosuid" "nodev" "mode=750" ]; }; </ins> } // optionalAttrs (!config.boot.isContainer) { # systemd-nspawn populates /sys by itself, and remounting it causes all # kinds of weird issues (most noticeably, waiting for host disk device

Discussion:
Currently NixOS has some special support for creating a RAM FS for . Unfortunately even though it lives in NixOS and NixOS includes a special "keys" group that is supposed to have access to that folder, support for the feature is sort of neutered without NixOps, which then applies this logic: To actually make the folder usable to members of the "keys" group. It seems like that logic should live on the NixOS side for those of us who want a reasonable place in RAM to drop certain keys, but don't use NixOps. cc since I don't really understand the NixOS/NixOps intricacies.
Wow, stumbled over that just now. Currently is owned by : This currently breaks some assumptions in the NixOS module system when not deployed with NixOps (like when deploying with morph, or autoscaling VMs at cloud providers setting up secrets in ). It'll also become more and more of a problem if we run less services as root, and assume users in the group have access to some secrets. I assume we might want to fix permission of the folder by adding a rule into nixpkgs - turning 2 of the three lines in nixops into a no-op. cc
Totally agree. :+1: to add a tmpfiles rule and remove that thing from nixops.
I'd still like to find out what makes special, and if we can remove things there without breaking anything ;-)
IIRC are the things that are mounted in the . i.e. they're used to generate the in and for some arbitrary reason also which seems the odd one out ;) Perhaps there is some usecase of loading secrets in initrd? Systemd's initrd has a similar procedure called
Yes, enabling sshd in initrd, unlock the root volume by having nixops send over the keys.
So, I did some digging. While assembling stage 1 and 2 scripts, the generated already contains the parameter. However, it seems like the kernel only honors this option for , not . I opened which removes this and uses tmpfiles to do the chgrp when necessary.
Change:
diff --git a/CMakeLists.txt b/CMakeLists.txt <del> index 1e7b71a..9db85b1 100644 </del> <ins> index 1e7b71a..e743ab0 100644 </ins> --- a/CMakeLists.txt +++ b/CMakeLists.txt <del> @@ -107,6 +107,8 @@ if(USE_SYSTEM_NCNN) </del> <ins> @@ -106,9 +106,9 @@ if(USE_SYSTEM_NCNN) message(STATUS "Using glslang install located at ${GLSLANG_TARGET_DIR}") </ins> find_package(Threads) <ins> +        find_package(SPIRV-Tools-opt REQUIRED) </ins> <del> +        include("${GLSLANG_TARGET_DIR}/SPIRV-Tools/SPIRV-ToolsTarget.cmake") +        include("${GLSLANG_TARGET_DIR}/SPIRV-Tools-opt/SPIRV-Tools-optTargets.cmake") </del> include("${GLSLANG_TARGET_DIR}/OSDependentTargets.cmake") <del> include("${GLSLANG_TARGET_DIR}/OGLCompilerTargets.cmake") </del> <ins> -        include("${GLSLANG_TARGET_DIR}/OGLCompilerTargets.cmake") </ins> if(EXISTS "${GLSLANG_TARGET_DIR}/HLSLTargets.cmake") <ins> # hlsl support can be optional include("${GLSLANG_TARGET_DIR}/HLSLTargets.cmake") </ins>

Discussion:
Steps to reproduce the behavior: Real-ESRGAN-ncnn-vulkan-0.2.0 error None I can think of <!-- 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]:
I am not a maintainer for this package. Seems like some others were pinged wrongfully as well.
I checked the commit logs, I don't think I pinged anyone by mistake. It said to "when in doubt run " which to my understanding just lists who committed recently, also I checked the commits by the main maintainer in the nix file and seems like he might not be very active, so I thought it best to ping few others for good measure. Sorry if I caused any annoyances, not my intention here
Change:
sha256 = "sha256-aHcVbSOnsz917uidL1wskcVCr8PNy2Nt6lqIU5pY0Qw="; }; <del> buildInputs = [ glib linuxHeaders ]; </del> <ins> buildInputs = [ glib gnutls ] ++ lib.optionals stdenv.isLinux [ linuxHeaders ]; </ins> nativeBuildInputs = [ pkg-config which bison ];

Discussion:
Thank you for packaging NBD! However, the current NBD package does not have TLS support. Is it possible to add TLS support to the compile process? Set and try to connect to an TLS-enabled server. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Change:
python2Packages.buildPythonApplication rec { name = "virt-manager-${version}"; <del> version = "1.4.3"; </del> <ins> version = "1.5.0"; </ins> namePrefix = ""; src = fetchurl { url = "http://virt-manager.org/download/sources/virt-manager/${name}.tar.gz"; <del> sha256 = "093azs8p4p7y4nf5j25xpsvdxww7gky1g0hs8mkcvmpxl2wjd0jj"; </del> <ins> sha256 = "d43a7b99d40acdcb8e9455e7874beee132cfcfce9eed0d6252e8f254a82cadc6"; </ins> }; nativeBuildInputs = [

Discussion:
Since , virtmanager no longer depends on pygtk; it is still listed in the dependencies though. Actually, most of the propagated dependencies are not mentioned anywhere in the virt-manager source code.
Change:
dataDir = "${seafRoot}/data"; seahubDir = "${seafRoot}/seahub"; <del> in { </del> <ins> in { </ins> ###### Interface

Discussion:
I upgraded to NixOS 23.11 from 23.05 and I didn't touch seafile configuration files. Now Seahub doesn't start anymore. Steps to reproduce the behavior: to NixOS 23.11 fails Seahub should start normally, the same as NixOS 23.05. <!-- 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]:
After searching more about this issue, I found , which should solve this once merged.
Change:
buildPythonPackage rec { pname = "python-imread"; version = "0.7.5"; <ins> pyproject = true; </ins> src = fetchPypi { inherit version; pname = "imread"; <del> sha256 = "sha256-GiWpA128GuLlbBW1CQQHHVVeoZfu9Yyh2RFzSdtHDbc="; </del> <ins> hash = "sha256-GiWpA128GuLlbBW1CQQHHVVeoZfu9Yyh2RFzSdtHDbc="; </ins> }; <ins> nativeBuildInputs = [ pkg-config setuptools ]; buildInputs = [ libjpeg libpng libtiff libwebp ]; </ins> <del> nativeBuildInputs = [ pkg-config ]; buildInputs = [ nose libjpeg libpng libtiff libwebp ]; </del> propagatedBuildInputs = [ numpy ]; <ins> nativeCheckInputs = [ pytestCheckHook ]; pytestFlagsArray = [ # verbose build outputs needed to debug hard-to-reproduce hydra failures "-v" "--pyargs" "imread" ]; pythonImportsCheck = [ "imread" ]; preCheck = '' cd $TMPDIR export HOME=$TMPDIR export OMP_NUM_THREADS=1 ''; </ins> meta = with lib; { description = "Python package to load images as numpy arrays"; homepage = "https://imread.readthedocs.io/en/latest/";

Discussion:
since 2024-01-14. Steps to reproduce the behavior: 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]:
I can reproduce. This may require an upstream fix
No upstream fix, but this PR fixes it:
Change:
, seccompSupport ? stdenv.isLinux, libseccomp , pulseSupport ? !stdenv.isDarwin, libpulseaudio , sdlSupport ? !stdenv.isDarwin, SDL2 <del> , gtkSupport ? !stdenv.isDarwin && !xenSupport, gtk3, gettext, vte </del> <ins> , gtkSupport ? !stdenv.isDarwin && !xenSupport, gtk3, gettext, vte, wrapGAppsHook </ins> , vncSupport ? true, libjpeg, libpng , smartcardSupport ? true, libcacard , spiceSupport ? !stdenv.isDarwin, spice, spice-protocol

Discussion:
Describe the bug On the branch 19.09, when i start a test interactively, the QEMU process segfaults. It works well when executed non interactively. To Reproduce In the kernel logs, i can see: Additional context The host kernel is and the nixpkgs commit of the NixOS deployment is (release 19.03). It seems to be working fine for a friend of mine, so it may be related to the execution environment.
I've been running VMs off unstable and 19.09 all week without issues. (host runs unstable) I believe it's because your host system is on 19.03 and the configuration you've built to run interactively is on 19.09. Though I wouldn't expect this to segfault, I've seen things like this happen before in a similar circumstance.
I upgraded to my host to 19.09 and i still run into this issue:( are you running VMs interactively?
Yes I have Perhaps hardware information could benefit this report, it could be an issue in QEMU.
So, I just tried to run the vm as root and it works well:/
if you're on a default 19.09, there should be a coredump, available via . Could you post the backtrace here - it might be helpful.
Thanks to the core dump, i have disable qemu () in the test vm and the process is no longer segfaulting! So, the culprit seems to be gtk. Here is the trace:
a segfault in sounds scary - what CPU is this running on?
Ok, it works well when I . It seems to be the same kind of issue than
cc
I guess it needs a wrapper. Pretty sure you don't run into ever if the executable is wrapped.
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 . 3. Ask on the on .
It seems simply invokes , and wrapping gtk binaries is as simple as , so I opened this PR. I'd appreciate if you could test this, as I wasn't able to reproduce this issue locally.
I'm unfortunately no longer able to reproduce:(
Change:
nativeBuildInputs = [ cmake ]; <del> buildInputs = [ libjack2 libpulseaudio ] ++ lib.optional stdenv.isLinux alsa-lib </del> <ins> buildInputs = [ libjack2 ] ++ lib.optionals stdenv.isLinux [ libpulseaudio alsa-lib ] </ins> ++ lib.optional stdenv.isDarwin AudioUnit; <ins> cmakeFlags = lib.optionals stdenv.isDarwin [ "-DBUILD_TESTS=OFF" ]; </ins> NIX_CFLAGS_COMPILE = lib.optionalString stdenv.isDarwin "-Wno-strict-prototypes"; meta = with lib; {

Discussion:
Steps to reproduce the behaviour: Shell opens with libsoundio available. Build fails with the error In file included from ../src/pulsecore/core-util.c:114: /nix/store/b9bh3z78rqff14bf0fd78xb07b5cnwdw-clang-wrapper-11.1.0/resource-root/include/cpuid.h:11:2: error: this header is for x86 only. Note that even tho error itself belongs to a dependency , I'm reporting because I assume shouldn't be a dependency when building for macOS, or at least there should be a way to disable it. Add any other context about the problem here. Please run and paste the result.