jiebi/CodeConvo huggingface dataset:
Change:
<del> { lib, stdenv, fetchFromGitHub, python3, makeWrapper }: </del> <ins> { lib, stdenv, fetchFromGitHub, python3, makeWrapper, libarchive }: </ins> let <del> pythonEnv = python3.withPackages(ps: with ps; [ cheetah3 ]); </del> <ins> pythonEnv = python3.withPackages(ps: with ps; [ cheetah3 lxml ]); </ins> in stdenv.mkDerivation rec { pname = "sickgear"; <del> version = "0.25.35"; </del> <ins> version = "0.25.40"; </ins> src = fetchFromGitHub { owner = "SickGear"; repo = "SickGear"; rev = "release_${version}"; <del> sha256 = "0hc43wfa256nkjm7bvsr6b7xsyilm1ks4x16kvpprqmj1symlkz3"; </del> <ins> sha256 = "sha256-AHV/HSKuVWZFdZdkFp9p7okAcFO40d9OqV20MaHKXaU="; </ins> }; <ins> patches = [ ./patches/override-python-version-check.patch ]; </ins> dontBuild = true; doCheck = false; nativeBuildInputs = [ makeWrapper ]; <del> buildInputs = [ pythonEnv ]; </del> <ins> buildInputs = [ pythonEnv libarchive ]; </ins> postPatch = '' substituteInPlace sickgear.py --replace "/usr/bin/env python2" "/usr/bin/env python"

Discussion:
A number of dependencies which are technically optional (but without which some features don't work) appear to be missing from the SickRage package: (Presumably this requires some Python package?) (Presumably this requires ?) Steps to reproduce the behavior: SickGear from nixpkgs subtitle fetching a show with subtitles enabled at regular logs (for the subtitle warning) and error logs (for the rar error) I'm not entirely sure when or why SickGear fetches the file, but I think the subtitle fetch is attempted when a show episode is being searched for. Features should work out of the box. N/A N/A Please run and paste the result. Note: SickGear is installed from , even though I am running stable.
The only problem I can see is that unrar is unfree.... Just looking through the , it looks like it can also use bsdtar from libarchive.... so I'm not sure the best way to handle it.
Maybe you can test out
Change:
pkgs.runCommand "test-mbuffer" {} '' echo hello | ${emulator} ${mbuffer}/bin/mbuffer ''; <ins> # This is meant to be a carefully curated list of builds/packages # that tend to break when refactoring our cross-compilation # infrastructure. # # It should strike a balance between being small enough to fit in # a single eval (i.e. not so large that hydra-eval-jobs is needed) # so we can ask @ofborg to check it, yet should have good examples # of things that often break.  So, no buckshot `mapTestOnCross` # calls here. sanity = [ #pkgs.mbuffer              # https://github.com/NixOS/nixpkgs/issues/213453 #pkgs.pkgsCross.gnu64.bash # https://github.com/NixOS/nixpkgs/issues/243164 pkgs.gcc_multi.cc pkgs.pkgsMusl.stdenv pkgs.pkgsLLVM.stdenv pkgs.pkgsStatic.bash pkgs.pkgsCross.arm-embedded.stdenv pkgs.pkgsCross.aarch64-multiplatform.pkgsBuildTarget.gcc #pkgs.pkgsCross.powernv.pkgsBuildTarget.gcc pkgs.pkgsCross.mips64el-linux-gnuabi64.stdenv pkgs.pkgsCross.mips64el-linux-gnuabin32.stdenv pkgs.pkgsCross.mingwW64.stdenv ]; in { gcc = (lib.mapAttrs (_: mapMultiPlatformTest (system: system // {useLLVM = false;})) tests); llvm = (lib.mapAttrs (_: mapMultiPlatformTest (system: system // {useLLVM = true;})) tests); inherit mbuffer sanity; </ins> }

Discussion:
Until recently, nixpkgs' cross-compilation infrastructure was considered a sort of exotic/best-effort thing, without much CI or testing until things got to Hydra. That's no longer the case, and we are starting to depend on for increasingly important stuff. We need a package-sized (i.e. not needing ) build that people can run when refactoring our cross-compilation infrastructure. When I wrote I tested it thouroughly on all the s I encounter on a regular basis, but since I don't use LLVM much or Windows at all I neglected to try and . .
Can we cross-compile from to Darwin without Apple-proprietary tooling? If so, this should include some basic test of that.
Change:
./services/desktops/zeitgeist.nix ./services/development/bloop.nix ./services/development/blackfire.nix <ins> ./services/development/distccd.nix </ins> ./services/development/hoogle.nix ./services/development/jupyter/default.nix ./services/development/jupyterhub/default.nix

Discussion:
Proposed options: (bool: ) (signed integer: ) (list of strings: )
Can you elaborate a bit more? Are you thinking of running a ? Or do you want to enable distcc as a client by default? In the first case you can easily define a systemd-service in nix, but across untrusted networks, you should run over ssh (which does not need a permanently running daemon). For a client, you can easily set up in a Also have a look at and .
I marked this as stale due to inactivity. &rarr;
I'm working on this.
Change:
services.xserver.desktopManager.session = [{ name = "xfce"; <ins> desktopNames = [ "XFCE" ]; </ins> bgSupport = true; start = '' ${pkgs.runtimeShell} ${pkgs.xfce.xfce4-session.xinitrc} &

Discussion:
Describe the bug The default applications menu of Xfce and Mate desktop environments use to present preferences items and a control center (or similar) item for system configuration. Those items stopped appearing in the menu. Screenshots Screenshots taken for Xfce and Mate running in a local virtual machine: ! ! Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
With the following changes in the services they work again: cc
Likely caused by
PR fixes this issue for Mate. Can it be merged? cc
I guess we have too.
Does need backport is the question.
I think so.
Would a similar solution (use upstream session) work for XFCE?
I had to revert it actually, because people can't combine wm and desktop manager :frowning:
The environment variable can be set to explicitly in the xfce desktop module. At least until a more well structured solution comes up.
That can do it, it would have to be in .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
<del> #!/usr/bin/env nix-shell #! nix-shell -i bash -p nodePackages.node2nix node2nix -6 -i deps.json  -e ../../../development/node-packages/node-env.nix  --no-copy-node-env  -c node.nix </del>

Discussion:
zed uses the binary release of (at this time still called ), while the newest version is . As this is basically a Chromium binary that can execute arbitrary Javascript and deliberately breaks all sandboxing features, we should at least keep it on a current version. cc I’m pushing an update of to 0.26 at the moment, but the package can’t handle it, so I’m pinning to for the time being.
Hi Thanks a lot for working on this. It's been a while ago since I worked on this part of , but I slightly remember that I had to deal with several outdated versions when dealing with . I'll definitely have a look into this in the next days, hopefully there's a patch by some contributors (or it's easy to file one to fix this). However the project isn't too active, so at least when we suffer from more further breaks or security issues because of severely outdated dependencies, we shouldn't hesitate to mark this package as broken or even drop it entirely (unless there are folks heavily relying on this).
I’d be in favor of a drop; people will complain if they still use it, if that happens we can restore & update, or the package is pulled outside of nixpkgs until someone can push and maintain a recent update.
In fact I agree with you, I've observed this "restore & update" pattern with some bigger applications (especially web-services) and I think that this is unneeded extra-work for the nixpkgs maintainers and release managers before each release. Before I file a patch to either {drop it,mark it as broken} or fix the dependency issue, I'd like to check two things before: is there any active fork? I'd like to ensure that the project is actually dead/unresponsive or does it have a working/maintained fork? check in the IRC if there are active users (I don't use it, I just fixed the derivation to help to get rid of ). If there are any, we should ask them to take over maintenance (or ask them to create their own overlay) I'll try to have a deeper look into it tonight, when I know more and have an actual opinion on how to proceed, I'll leave a comment here.

As far as I know, the author is no longer actively developing Zed anymore: I happen to know him personally, but as far as I know he has no interests in doing any major additional developments any time soon. Of course, I can always ask but I think I already know the answer. :) For me it's fine if it gets removed.
ok I suspected something like this as the last commit was from 2015. In this case I'm also :+1: for dropping it...
just submitted a PR for now, I asked in the IRC if there are any folks using , if I don't get a response, I'd just vote for merging it to master and do a backport to 18.03
Change:
xineLib = xine-lib; # Added 2021-04-27 xineUI = xine-ui; # Added 2021-04-27 xmlada = gnatPackages.xmlada; # Added 2024-02-25 <del> xonsh-unwrapped = xonsh.passthru.unwrapped; </del> <ins> xonsh-unwrapped = python3Packages.xonsh; # Added 2024-06-18 </ins> xtrt = throw "xtrt has been removed due to being abandoned"; # Added 2023-05-25 xulrunner = firefox-unwrapped; # Added 2023-11-03 xvfb_run = xvfb-run; # Added 2021-05-07

Discussion:
Xonsh because of However, in unstable the is using
cc as maintainer
I am waiting for someone hit the button here: P.S.: I am not waiting anymore.
Upstream has unpinned prompt-toolkit after

Upstream issue: Since the issue seems to be specific to NixOS, let's track it here. The two commands above should only print "True". If applicable, add screenshots to help explain your problem. Tested on xonsh 0.13.3 and 0.13.4 system: host os: multi-user?: sandbox: version: nixpkgs:
Upstream fix:
Change:
{ lib , fetchFromGitHub , python3 <del> , python3Packages </del> }: <del> python3Packages.buildPythonApplication rec { </del> <ins> python3.pkgs.buildPythonApplication rec { </ins> pname = "gyb"; <del> version = "1.80"; </del> <ins> version = "1.81"; </ins> format = "other"; src = fetchFromGitHub { owner = "GAM-team"; repo = "got-your-back"; rev = "refs/tags/v${version}"; <del> sha256 = "sha256-4xElzhf9R6qnzr4oyZktQy/ym2vEjR9MrHnLYxBiAOg="; </del> <ins> hash = "sha256-ViNOEH5wyAQRR56egRhh4JoP1PWOCr+rxFmqxfJiu+0="; </ins> }; <del> propagatedBuildInputs = with python3Packages; [ </del> <ins> dependencies = with python3.pkgs; [ </ins> google-api-python-client google-auth google-auth-oauthlib

Discussion:
Steps to reproduce the behavior: gyb Seems to fail both on master and on latest unstable. 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:
nativeBuildInputs = [ pkgconfig autoreconfHook ] <ins> ++ optional stdenv.isDarwin hexdump </ins> ++ optional withGui wrapQtAppsHook; buildInputs = [ openssl db48 boost zlib zeromq miniupnpc libevent]

Discussion:
Describe the bug nix-shell -p bitcoind fails with: Metadata Please run and paste the result. (I'm running nixpkgs-unstable, and I just updated the channel) Maintainer information:
Change:
<ins> --- ./vendor/modules/code-oss-dev/node_modules/playwright/install.js +++ ./vendor/modules/code-oss-dev/node_modules/playwright/install.js @@ -14,6 +14,4 @@ * limitations under the License. */ -const { installDefaultBrowsersForNpmInstall } = require('playwright-core/lib/utils/registry'); - -installDefaultBrowsersForNpmInstall(); +process.stdout.write('Browser install disabled by Nix build scriptn'); </ins>

Discussion:
Currently, code-server (and openvscode-server) depends on 16 in nixpkgs, for the upcoming release of NixOS 23.11, this dependency must be dropped, and all upgrades must be performed to 18. From what I see on — 18 is supported as an engine. Otherwise, those programs are to be dropped. Please pick up the pieces cc
Drop will be performed in
Change:
<ins> { buildGoModule, buildNpmPackage, fetchFromGitHub, lib }: let frontend = buildNpmPackage rec { pname = "filebrowser-frontend"; version = "2.23.0"; src = fetchFromGitHub { owner = "filebrowser"; repo = "filebrowser"; rev = "v${version}"; hash = "sha256-xhBIJcEtxDdMXSgQtLAV0UWzPtrvKEil0WV76K5ycBc="; }; sourceRoot = "source/frontend"; npmDepsHash = "sha256-acNIMKHc4q7eiFLPBtKZBNweEsrt+//0VR6dqwXHTvA="; NODE_OPTIONS = "--openssl-legacy-provider"; installPhase = '' runHook preInstall mkdir $out mv dist $out runHook postInstall ''; }; in buildGoModule rec { pname = "filebrowser"; version = "2.23.0"; src = fetchFromGitHub { owner = "filebrowser"; repo = "filebrowser"; rev = "v${version}"; hash = "sha256-xhBIJcEtxDdMXSgQtLAV0UWzPtrvKEil0WV76K5ycBc="; }; vendorHash = "sha256-MR0ju2Nomb3j78Z+1YcJY+jPd40MZpuOTuQJM94AM8A="; excludedPackages = [ "tools" ]; preBuild = '' cp -r ${frontend}/dist frontend/ ''; passthru = { inherit frontend; }; meta = with lib; { description = "Filebrowser is a web application for managing files and directories"; homepage = "https://filebrowser.org"; license = licenses.asl20; maintainers = with maintainers; [ nielsegberts ]; }; } </ins>

Discussion:
Project description Lightweight nextcloud/seafile/syncthing/ftp alternative to easily share files with mutiple users via HTTP Metadata homepage URL: source URL: license: Apache License platforms: any
I marked this as stale due to inactivity. &rarr;
need this too
I also have a work in progress for a module that wraps FileBrowser
If you submit a PR I can help review or test it
I've not quite sure how stacked PR's work on github as the previous one is still pending, but it would be great if you could test and leave feedback on this commit:
I've opened a new issue to discuss the options:
Change:
<ins> #!/usr/bin/env nix-shell #!nix-shell -I nixpkgs=../ -i bash -p wget yarn2nix set -euo pipefail if [ "$#" -ne 1 ] || [[ "$1" == -* ]]; then echo "Regenerates the Yarn dependency lock files." echo "Usage: $0 <git release tag>" exit 1 fi SRC="https://raw.githubusercontent.com/matrix-org/seshat/$1" wget "$SRC/seshat-node/yarn.lock" yarn2nix > yarn.nix rm yarn.lock </ins>

Discussion:
Describe the bug Riot-Desktop -Security & Privacy Under the "Message search" heading, observe: Riot is missing some components required for securely caching encrypted messages locally. If you'd like to experiment with this feature, build a custom Riot Desktop with search components . it links to here: Notify maintainers cc: Metadata Maintainer information:
Would be fantastic to have built with . I tried building it myself but couldn't do it. :cry:
Just stumbled across this myself. What's the current state on this? What needs to be done before this can be fixed?
So, element seems to use its own build system to build these native dependencies. It tries to download and build those itself with cargo and stuff. Seems quite complicated to package.
I would like to add that support for desktop notifications would be also appreciated. (They showed up on Arch's version, at least) Edit: This problem has been resolved since
I made some progress. This solves the issue of downloading the hakDependencies. Unfortunately they are not locked in any way, so we need to lock them at packaging-time (is that even a term?) by adding them to and Since yarn2nix always runs yarn with , we can safely ignore the upstream reasoning for fetching them outside of yarn dependencies. I'm now at the point where it tries to build seshat in the element-desktop derivation, but unfortunately they don't provide a Cargo lockfile. I'm working on resolving this problem upstream: <details</details
It turns out to be much more complicated, because the cargo build of seshat-node-native calls , so we have multiple layers of npm calling yarn calling cargo calling npm. With lots of things being downloaded and executed. It's a huge shitshow.
Is there anything we could do to help fix building with encrypted chat search working on NixOS?
I poured some (many) more hours into this today. I can build the two native modules, matrix-seshat and keytar, both in a seperate derivation and as part of the element-desktop build. However, I can not build them correctly against electron's node lib, so when starting the compiled thing, it refuses to load the module. Attempting to build against electron gives a mystic error.

Or the second approach, with everything in one derivation using the hak tool: <details</details<rantHonestly it's just a horrible build system. hak and neon and so on don't give any consideration to users who want to build the libraries in an environment without an internet connection. </rant If you can find a fix for the error, there shouldn't be much work left.
I think I found the solution to that error: Upstream is using Electron 12.x while we are using Electron 13.x.
! PR incoming :sparkles:
Change:
<ins> { stdenv , fetchFromGitHub , fetchpatch , cmake , cryptominisat , boost , louvain-community , lib }: stdenv.mkDerivation (finalAttrs: { pname = "arjun-cnf"; version = "2.5.2"; src = fetchFromGitHub { owner = "meelgroup"; repo = "arjun"; rev = finalAttrs.version; hash = "sha256-5duc05s654HLjbf+dPgyMn6QUVvB0vLji3M4S2o/QYU="; }; # Can be removed after next release patches = [ (fetchpatch { url = "https://github.com/meelgroup/arjun/commit/34188760f1ab4b1b557c45ccaee8d2b9b6f0b901.patch"; hash = "sha256-E/yk2ohHP2BAFg353r8EU01bZCqeEjvpJCrBsxPiOWM="; }) # Based on https://github.com/meelgroup/arjun/commit/99c4ed4ad820674632c5d9bbcc98c001f8cac98f ./fix-red-clause.patch ]; nativeBuildInputs = [ cmake ]; buildInputs = [ boost cryptominisat louvain-community ]; meta = with lib; { description = "CNF minimizer and minimal independent set calculator"; homepage = "https://github.com/meelgroup/arjun"; license = licenses.mit; maintainers = with maintainers; [ t4ccer ]; platforms = platforms.linux; mainProgram = "arjun"; }; }) </ins>

Discussion:
Project description is an approximate model counter for CNF formulas. Metadata homepage URL: source URL: license: mit platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> { lib, buildGraalvmNativeImage, fetchurl }: </del> <ins> { lib, buildGraalvmNativeImage, graalvmCEPackages, removeReferencesTo, fetchurl }: </ins> buildGraalvmNativeImage rec { pname = "clj-kondo"; version = "2023.10.20"; src = fetchurl { <del> url = "https://github.com/clj-kondo/${pname}/releases/download/v${version}/${pname}-${version}-standalone.jar"; </del> <ins> url = "https://github.com/clj-kondo/${pname}/releases/download/v${version}/${pname}-${version}-standalone.jar"; </ins> sha256 = "sha256-f9u/pk3CEEmiLgnS2biaUHpsMHjVEwZL2jyB/1PiZUY="; }; <del> extraNativeImageBuildArgs = [ "-H:+ReportExceptionStackTraces" "--no-fallback" ]; </del> <ins> graalvmDrv = graalvmCEPackages.graalvm-ce; nativeBuildInputs = [ removeReferencesTo ]; extraNativeImageBuildArgs = [ "-H:+ReportExceptionStackTraces" "--no-fallback" ]; postInstall = '' remove-references-to -t ${graalvmDrv} $out/bin/${pname} ''; </ins> meta = with lib; { description = "A linter for Clojure code that sparks joy"; homepage = "https://github.com/clj-kondo/clj-kondo"; sourceProvenance = with sourceTypes; [ binaryBytecode ]; license = licenses.epl10; <del> changelog = "https://github.com/clj-kondo/clj-kondo/blob/v${version}/CHANGELOG.md"; </del> <ins> changelog = "https://github.com/clj-kondo/clj-kondo/blob/v${version}/CHANGELOG.md"; </ins> maintainers = with maintainers; [ jlesquembre bandresen thiagokokada ]; }; }

Discussion:
Install clj-kondo and the following error occurs: No trouble installing clj-kondo a few weeks ago so could be a problem specific to the if not my setup. <details<summary</code</summary</detailsclj-kondo should be installed. Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I'm noticing a similar error when trying to build clojure-lsp or jet. FWIW, the above as returned by nix-info seems bogus: I'm running macOS Ventura 13.6.1 I'm using nix-darwin.
Seems that only darwin is affected:
The problematic packages depend on the Oracle version of GraalVM.
This is probably caused by this line: The reason we have it is to avoid having packages depending on derivation itself (that is quite big). We could remove the but the ideal fix is to identify what GraalVM is linking in the final derivations and remove the reference, e.g.:
would it be enough to add the following to the clj-kondo package?
I actually don't know, ideally you need to check why the binary is having references to the GraalVM derivation to make sure if this is safe or not. To do so you can remove the , build a binary, run and check the reason.
I built a copy of clj-kondo without the and took a look at strings, but nothing jumps out at me.
Ok, I think it is fair to just call in the resulting binary.
i have the same problem with clojure-lsp. Should it be possible to apply the same fix there?
Change:
release instead of 1.0.x </para> </listitem> <ins> <listitem> <para> If <literal>exfat</literal> is included in <literal>boot.supportedFilesystems</literal> and when using kernel 5.7 or later, the <literal>exfatprogs</literal> user-space utilities are used instead of <literal>exfat</literal>. </para> </listitem> </ins> </itemizedlist> </section> <section xml:id="sec-release-21.11-notable-changes">

Discussion:
Describe the bug On kernels newer than 5.8 exfat is natively supported by the kernel. However, if is used, nix will pull in exfat package and will use the fuse driver. This can be bypassed by not using the type and mounting by hand (there is no link for , but works still). To Reproduce Steps to reproduce the behavior: an exfat volume it to the attribute, e.g. that filesystem type is using . Expected behavior Using native kernel module for mounting exfat filesystems when kernel version is newer than 5.8. Additional context A check alike this already exists for the package () It seems that the check in could be responsible for this. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
should be for proper userspace to go with the new in kernel driver
Just got bitten by this on . Both FUSE and native can coexist, but if (from the package) is in the path, the utility will prefer it unless called with the flag (even with ). As there's no way to disable the utility from being built from current exfat, I suggest we switch to (I can submit a PR to package this) for applicable kernels.
Can confirm this behavior, having exfatprogs with newer kernels is definitely recommended.
Change:
sha256 = "1gb8vb1wl7ikn269dd1c7ihqhkyrwk19jwx5kd0rdvbk6g7g25ix"; }; <ins> patches = [ # https://build.opensuse.org/request/show/843612 ./CVE-2019-19917-and-CVE-2019-19918.patch ]; </ins> buildInputs = [ ghostscript ]; builder = ./builder.sh;

Discussion:
, CVSSv3=7.8 (nixos-20.09, nixos-unstable) Scanned versions: nixos-20.09: ; nixos-unstable: .
See also:

, CVSSv3=7.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives.
Change:
libopenshot = callPackage ../development/libraries/libopenshot { stdenv = if pkgs.stdenv.isDarwin then pkgs.overrideSDK pkgs.stdenv "11.0" else pkgs.stdenv; <ins> python3 = pkgs.python311; </ins> }; packagekit-qt = callPackage ../tools/package-management/packagekit/qt.nix { };

Discussion:
Steps to reproduce the behavior: openshot-qt on nixos-unstable () Recently the default python was changed from 3.11 to 3.12, reverting to 3.11 works. Additionally on 3.11 sip can be upgraded from to (version 6) and it builds and runs, but using sip 6 with python 3.12 will result in a segfault. <!-- 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]:
The segfault with python 3.12 (and 6) is related to