Question: { lib, stdenv, callPackage, fetchFromGitHub, autoreconfHook, pkg-config , CoreFoundation, IOKit, libossp_uuid <del> , curl, libcap,  libuuid, lm_sensors, zlib </del> , nixosTests <ins> , curl, libcap, libuuid, lm_sensors, zlib </ins> , withCups ? false, cups , withDBengine ? true, libuv, lz4, judy , withIpmi ? (!stdenv.isDarwin), freeipmi , withNetfilter ? (!stdenv.isDarwin), libmnl, libnetfilter_acct <ins> , withCloud ? (!stdenv.isDarwin), json_c </ins> , withSsl ? true, openssl , withDebug ? false <del> , fetchpatch </del> }: with lib;

Project description Netdata agent plugin Metadata homepage URL: source URL: license: GPL 3.0 platforms: unix, linux, darwin We already do have netdata, however it seems to be built without support for the cloud agent that allows it to stream to the cloud or other netdata servers.
I have a local checkout with some edits that allow me to build netdata with cloud support. Unfortunately they also require a change in the libwebsockets build expression. Should I open a PR to integrate my changes into nixpkgs?
A PR would be great! I'm not a maintainer, but if they decide it's out of scope for nixpkgs, perhaps one on NUR might work - I'd try for a PR here first though
Great, I think having a configuration option that is per default would make sense. Maybe ?
Yeah, that seems to fall in line with the various flags present in other packages
I marked this as stale due to inactivity. →
Upstream has incorporated some of the suggestions in this thread, I intend to pick up on it again soon
what would be needed to make this work? Perhaps I can help?
The newest major release of Netdata (1.30.0) includes a cloud link implementation without the need for vendored dependencies. Unfortunately, it is not currently in a reliable state because of a bug in the custom HTTPS implementation. The has already been merged into Netdata master and will be included in the next release. I plan to make a PR that enables cloud support as soon as that release is available.
v1.31.0 dropped 12 minutes ago :) Anything I can do to help?
Thanks, I've already gotten a notification for that. Planning to make a PR when I get off work today. When my PR is done, it would be helpful if you could test my changes on your machines.
Just FYI, I have opened the PR that enables cloud support a few days ago. If you are still interested it would be greatly appreciated if you could test if everything works for you and maybe drop a comment.
Sorry, missed this but the pr looks good! I propose we backport this to stable?


Question: <ins> { stdenv, config, lib, fetchurl, cmake, doxygen, extra-cmake-modules, wrapGAppsHook # For `digitaglinktree` , perl, sqlite , libsForQt5 , bison , boost , eigen , exiv2 , ffmpeg_4 , flex , graphviz , imagemagick , lcms2 , lensfun , libgphoto2 , liblqr1 , libusb1 , libheif , libGL , libGLU , opencv , pcre , x265 , jasper # For panorama and focus stacking , enblend-enfuse , hugin , gnumake , cudaSupport ? config.cudaSupport , cudaPackages ? {} }: stdenv.mkDerivation rec { pname   = "digikam"; version = "8.2.0"; src = fetchurl { url = "mirror://kde/stable/${pname}/${version}/digiKam-${version}.tar.xz"; hash = "sha256-L3/LVZsSPtnsrlpa729FYO7l9JIG2dF0beyatsj7OL8="; }; strictDeps = true; depsBuildBuild = [ cmake ]; nativeBuildInputs = [ cmake doxygen extra-cmake-modules libsForQt5.kdoctools libsForQt5.wrapQtAppsHook wrapGAppsHook ] ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_nvcc ]); buildInputs = [ bison boost eigen exiv2 ffmpeg_4 flex graphviz imagemagick lcms2 lensfun libgphoto2 libheif liblqr1 libusb1 libGL libGLU opencv pcre x265 jasper ] ++ (with libsForQt5; [ libkipi libksane libqtav qtbase qtxmlpatterns qtsvg qtwebengine qtnetworkauth akonadi-contacts kcalendarcore kconfigwidgets kcoreaddons kfilemetadata knotifications knotifyconfig ktextwidgets kwidgetsaddons kxmlgui breeze-icons marble oxygen threadweaver ]) ++ lib.optionals cudaSupport (with cudaPackages; [ cuda_cudart ]); cmakeFlags = [ "-DENABLE_MYSQLSUPPORT=1" "-DENABLE_INTERNALMYSQL=1" "-DENABLE_MEDIAPLAYER=1" "-DENABLE_QWEBENGINE=on" "-DENABLE_APPSTYLES=on" "-DCMAKE_CXX_FLAGS=-I${libsForQt5.libksane}/include/KF5" # fix `#include <ksane_version.h>` ]; dontWrapGApps = true; preFixup = '' qtWrapperArgs+=("''${gappsWrapperArgs[@]}") qtWrapperArgs+=(--prefix PATH : ${lib.makeBinPath [ gnumake hugin enblend-enfuse ]}) qtWrapperArgs+=(--suffix DK_PLUGIN_PATH : ${placeholder "out"}/${libsForQt5.qtbase.qtPluginPrefix}/${pname}) substituteInPlace $out/bin/digitaglinktree  --replace "/usr/bin/perl" "${perl}/bin/perl"  --replace "/usr/bin/sqlite3" "${sqlite}/bin/sqlite3" ''; meta = with lib; { description = "Photo Management Program"; license = licenses.gpl2; homepage = "https://www.digikam.org"; maintainers = with maintainers; [ spacefault ]; platforms = platforms.linux; mainProgram = "digikam"; }; } </ins>

Package name: digikam Latest released version: 8.2.0 Current version on the unstable channel: 8.1.0 Current version on the stable/release channel: 8.1.0 Notify maintainers Changelog: Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: , glfw , xorg , gamescopeSupport ? true # build mangoapp and mangohudctl <ins> , lowerBitnessSupport ? stdenv.hostPlatform.is64bit # Support 32 bit on 64bit </ins> , nix-update-script }:

Mangohud no longer appears on gnome/wayland when opening a game. "rev": "", (works) "rev": "", (doesn't) Steps to reproduce the behavior: a game on gnome/wayland doesn't appear even when enabled (worked in previous revision of nixpkgs above) ... Mangohud shows system stats Please run and paste the result.
I have the same problem too. I'm using Hyprland btw.
Oh weird. I'll try looking into this. The only thing that really sticks out to me in the diff is possibly ? - but it seems unlikely. I'll do a git bisect to try to narrow it down better.
If it helps you narrow down, here's my repo with the exact commit where mangohud stopped working. If I revert back to previous commit mangohud starts working again:
I bisected it, it's cc
mangohud uses its own internal copy of vulkan-headers: So it's probably the loader? If it is though, it might be tricky to bisect...
So, what are we going to do? Especially w.r.t. 23.05 being around the door. I don't think we should ship a broken mangohud in 23.05. Honestly, I think should have probably not made it to master before branch-off. (Eventhough it was technically merged a few dasy before breaking changes were restricted.)
I'll try to reproduce locally and see if I can bisect vulkan-loader.
cc because of
We could also try updating the headers externally; Mangohud's are really quite old. They use this weird meson wrap thingy rather than letting the distro provide it and it too is very out of date. Also, this is the error we're getting: (This is on 64-bit-only Mangohud.)
It breaks when built with newer headers.
Oh sorry, forgot to get back to this! Maybe we need to switch back to using the system headers?
I'm actually pretty sure it's which we probably don't want to revert, but we may need to look into layer ordering?
oh no - yeah i think you're right, i think the duplicate behaviour was specifically to support multi-arch layers (from what I remember).


Question: , glfw , xorg , gamescopeSupport ? true # build mangoapp and mangohudctl <ins> , lowerBitnessSupport ? stdenv.hostPlatform.is64bit # Support 32 bit on 64bit </ins> , nix-update-script }:

If it's just an issue of duplicate layers, perhaps we could add 32 and 64 suffixes to the layer names. obs-vkcapture does that too.
I gave up o pursuing this, as seen in It works, but for this case here, it's probably better to bring attention upstream. Cc
Having only the 64-bit mangohud json in the implicit layer dir works! Going to try giving the 32-bit layer a different name now.
This is also going to affect vkbasalt too then - I haven't tried yet though - I'll take a look at fixing that too!
Speaking of, any reason you gave up on that? I personally really liked the good idea.
Different suffixes work! PR incoming.
It needed a proper rebase+bump to v1.3.250, and I couldn't figure out how to really take a good benefit from it.
Hm, I'll definitely try to pick it up after branch-off then.
Peculiarly, obs-vkcapture seem to do this for some time already: from gamescope might need this fix too.


Question: }; }; <del> eclipse-platform = eclipse-platform-46; eclipse-platform-45 = buildEclipse { name = "eclipse-platform-4.5"; description = "Eclipse platform"; sources = { "x86_64-linux" = fetchurl { url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5-201506032000/eclipse-platform-4.5-linux-gtk-x86_64.tar.gz; sha256 = "1510j41yr86pbzwf48kjjdd46nkpkh8zwn0hna0cqvsw1gk2vqcg"; }; "i686-linux" = fetchurl { url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5-201506032000/eclipse-platform-4.5-linux-gtk.tar.gz; sha256 = "1f97jd3qbi3830y3djk8bhwzd9whsq8gzfdk996chxc55prn0qbd"; }; }; }; eclipse-platform-451 = buildEclipse { name = "eclipse-platform-4.5.1"; description = "Eclipse platform"; </del> <ins> eclipse-sdk-37 = buildEclipse { name = "eclipse-sdk-3.7"; description = "Eclipse Classic"; </ins> sources = { "x86_64-linux" = fetchurl { <del> url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.1-201509040015/eclipse-platform-4.5.1-linux-gtk-x86_64.tar.gz; sha256 = "1m7bzyi20yss6cz74d7hvhxj1cddcpgzxjia5wcjycsvq33kkny0"; </del> <ins> url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops/R-3.7.2-201202080800/eclipse-SDK-3.7.2-linux-gtk-x86_64.tar.gz; sha256 = "0nf4nv7awhp1k8b1hjb7chpjyjrqnyszsjbc4dlk9phpjv3j4wg5"; </ins> }; "i686-linux" = fetchurl { <del> url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.1-201509040015/eclipse-platform-4.5.1-linux-gtk.tar.gz; sha256 = "17x8w4k0rba0c0v9ghxdl0zqfadla5c1aakfd5k0q9q3x3qi6rxp"; </del> <ins> url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops/R-3.7.2-201202080800/eclipse-SDK-3.7.2-linux-gtk.tar.gz; sha256 = "1isn7i45l9kyn2yx6vm88jl1gnxph8ynank0aaa218cg8kdygk7j"; </ins> }; }; }; <ins> eclipse_sdk_37 = eclipse-sdk-37; # backward compatibility, added 2016-01-30 </ins> <del> eclipse-platform-452 = buildEclipse { name = "eclipse-platform-4.5.2"; description = "Eclipse platform"; sources = { "x86_64-linux" = fetchurl { url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.2-201602121500/eclipse-SDK-4.5.2-linux-gtk-x86_64.tar.gz; sha256 = "13dsd5f5i39wd0sr2bgp57hd2msn8g2dnmw5j8hfwif22c62py47"; }; "i686-linux" = fetchurl { url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.2-201602121500/eclipse-SDK-4.5.2-linux-gtk.tar.gz; sha256 = "00jsmbrl4xhpbgd8hyxijgzqdic700kd3yw2qwgl0cs3ncvybxvq"; }; }; }; eclipse-platform-46 = buildEclipse { name = "eclipse-platform-4.6"; description = "Eclipse platform"; sources = { "x86_64-linux" = fetchurl { url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.6-201606061100/eclipse-SDK-4.6-linux-gtk-x86_64.tar.gz; sha256 = "02lfa0f4j53q4ks3nal4jxnm1vc6xck2k9zng58izfh49v73jyjd"; }; "i686-linux" = fetchurl { url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.6-201606061100/eclipse-SDK-4.6-linux-gtk.tar.gz; sha256 = "053hsy87jmr9phn934a4qny959d6inxjx8nlcmxa2165ra8d7qfr"; }; }; }; </del> <ins> ################### Eclipse with Plugins ############################################################################# </ins> eclipseWithPlugins = { eclipse, plugins ? [], jvmArgs ? [] }: let

See We should probably remove some of the Eclipse versions we have as we seem to be carrying lots of them. If there are objections to removing, we should at the very least clean up this area.
you can probably close this one now?


Question: <ins> { autoPatchelfHook, fetchurl, lib, stdenv }: stdenv.mkDerivation rec { pname = "julia-bin"; version = "1.8.0"; src = { x86_64-linux = fetchurl { url = "https://julialang-s3.julialang.org/bin/linux/x64/${lib.versions.majorMinor version}/julia-${version}-linux-x86_64.tar.gz"; sha256 = "sha256-6A1zLMt/eeAA15jLi2Vtw2QatZUW1uTlLhZ2UBeJKgA="; }; }.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}"); postPatch = '' # Julia fails to pick up our Certification Authority root certificates, but # it provides its own so we can simply disable the test. Patching in the # dynamic path to ours require us to rebuild the Julia system image. substituteInPlace share/julia/stdlib/v${lib.versions.majorMinor version}/NetworkOptions/test/runtests.jl  --replace '@test ca_roots_path() != bundled_ca_roots()'  '@test_skip ca_roots_path() != bundled_ca_roots()' ''; nativeBuildInputs = [ autoPatchelfHook ]; installPhase = '' runHook preInstall cp -r . $out runHook postInstall ''; # Breaks backtraces, etc. dontStrip = true; doInstallCheck = true; preInstallCheck = '' export JULIA_TEST_USE_MULTIPLE_WORKERS=true # Some tests require read/write access to $HOME. export HOME="$TMPDIR" ''; installCheckPhase = '' runHook preInstallCheck # Command lifted from `test/Makefile`. $out/bin/julia  --check-bounds=yes  --startup-file=no  --depwarn=error  $out/share/julia/test/runtests.jl runHook postInstallCheck ''; meta = { description = "High-level, high-performance, dynamic language for technical computing"; homepage = "https://julialang.org"; # Bundled and linked with various GPL code, although Julia itself is MIT. license = lib.licenses.gpl2Plus; maintainers = with lib.maintainers; [ ninjin raskin ]; platforms = [ "x86_64-linux" ]; mainProgram = "julia"; }; } </ins>

<!-- Note that these are hard requirements --<!-- 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 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: <!-- The current version can be found easily with the same process as 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: 1.7.3 desired version: <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
I started preparing the update in . Cc:


Question: }; eclipse_modeling_36 = eclipse-modeling-36; # backward compatibility, added 2016-01-30 <del> eclipse-sdk-37 = buildEclipse { name = "eclipse-sdk-3.7"; description = "Eclipse Classic"; </del> <ins> ################### Eclipse Platform ################################################################################# eclipse-platform = eclipse-platform-46; eclipse-platform-46 = buildEclipse { name = "eclipse-platform-4.6"; description = "Eclipse platform"; </ins> sources = { "x86_64-linux" = fetchurl { <del> url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops/R-3.7.2-201202080800/eclipse-SDK-3.7.2-linux-gtk-x86_64.tar.gz; sha256 = "0nf4nv7awhp1k8b1hjb7chpjyjrqnyszsjbc4dlk9phpjv3j4wg5"; </del> <ins> url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.6-201606061100/eclipse-SDK-4.6-linux-gtk-x86_64.tar.gz; sha256 = "02lfa0f4j53q4ks3nal4jxnm1vc6xck2k9zng58izfh49v73jyjd"; </ins> }; "i686-linux" = fetchurl { <del> url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops/R-3.7.2-201202080800/eclipse-SDK-3.7.2-linux-gtk.tar.gz; sha256 = "1isn7i45l9kyn2yx6vm88jl1gnxph8ynank0aaa218cg8kdygk7j"; </del> <ins> url = https://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.6-201606061100/eclipse-SDK-4.6-linux-gtk.tar.gz; sha256 = "053hsy87jmr9phn934a4qny959d6inxjx8nlcmxa2165ra8d7qfr"; </ins> }; }; }; <del> eclipse_sdk_37 = eclipse-sdk-37; # backward compatibility, added 2016-01-30 eclipse-cpp-37 = buildEclipse { name = "eclipse-cpp-3.7"; description = "Eclipse IDE for C/C++ Developers"; src = if stdenv.system == "x86_64-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/indigo/R/eclipse-cpp-indigo-incubation-linux-gtk-x86_64.tar.gz; sha256 = "14ppc9g9igzvj1pq7jl01vwhzb66nmzbl9wsdl1sf3xnwa9wnqk3"; } else fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/indigo/R/eclipse-cpp-indigo-incubation-linux-gtk.tar.gz; sha256 = "1cvg1vgyazrkinwzlvlf0dpl197p4784752srqybqylyj5psdi3b"; }; }; eclipse_cpp_37 = eclipse-cpp-37; # backward compatibility, added 2016-01-30 eclipse-cpp-42 = buildEclipse { name = "eclipse-cpp-4.2"; description = "Eclipse IDE for C/C++ Developers"; src = if stdenv.system == "x86_64-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/juno/SR2/eclipse-cpp-juno-SR2-linux-gtk-x86_64.tar.gz; sha256 = "1qq04926pf7v9sf3s0z53zvlbl1j0rmmjmbmhqi49473fnjikh7y"; } else fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/juno/SR2/eclipse-cpp-juno-SR2-linux-gtk.tar.gz; sha256 = "1a4s9qlhfpfpdhvffyglnfdr3dq5r2ywcxqywhqi95yhq5nmsgyk"; }; }; eclipse_cpp_42 = eclipse-cpp-42; # backward compatibility, added 2016-01-30 eclipse-cpp-43 = buildEclipse { name = "eclipse-cpp-4.3.2"; description = "Eclipse IDE for C/C++ Developers"; src = if stdenv.system == "x86_64-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/kepler/SR2/eclipse-cpp-kepler-SR2-linux-gtk-x86_64.tar.gz; sha256 = "16zhjm6bx78263b1clg75kfiliahkhwg0k116vp9fj039nlpc30l"; } else fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/kepler/SR2/eclipse-cpp-kepler-SR2-linux-gtk.tar.gz; sha256 = "0d6jlj7hwz8blx6csrlyi2h2prql0wckbh7ihwjmgclwpcpj84g6"; }; }; eclipse_cpp_43 = eclipse-cpp-43; # backward compatibility, added 2016-01-30 eclipse-cpp-44 = buildEclipse { name = "eclipse-cpp-4.4.2"; description = "Eclipse IDE for C/C++ Developers"; src = if stdenv.system == "x86_64-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/luna/SR2/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz; sha256 = "1vxwj7yihgipvrb3gksmddqkarzazpwk3mh1mjnw0i5xz2y32ba4"; } else fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/luna/SR2/eclipse-cpp-luna-SR2-linux-gtk.tar.gz; sha256 = "1yn7yzzx8izc199c8w4f7vrc0b08idyq0dn113i8123b0mxw5lkp"; }; }; eclipse_cpp_44 = eclipse-cpp-44; # backward compatibility, added 2016-01-30 eclipse-cpp-45 = buildEclipse { name = "eclipse-cpp-4.5.1"; description = "Eclipse IDE for C/C++ Developers, Mars release"; src = if stdenv.system == "x86_64-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/mars/1/eclipse-cpp-mars-1-linux-gtk-x86_64.tar.gz; sha256 = "1j6rsgr44kya2v7y34ifscajqk7lnq1w9m9fx4i0qgby84sy4xj7"; } else if stdenv.system == "i686-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/mars/1/eclipse-cpp-mars-1-linux-gtk.tar.gz; sha256 = "0qsbvjkq0ssxbnafh4gs8pfclynqis3nf7xlxx4w3k20jcjx7sr2"; } else throw "Unsupported system: ${stdenv.system}"; }; eclipse_cpp_45 = eclipse-cpp-45; # backward compatibility, added 2016-01-30 eclipse-cpp-46 = buildEclipse { name = "eclipse-cpp-4.6.0"; description = "Eclipse IDE for C/C++ Developers, Neon release"; src = if stdenv.system == "x86_64-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/neon/R/eclipse-cpp-neon-R-linux-gtk-x86_64.tar.gz; sha256 = "09fqsgvbjfdqvn7z03crkii34z4bsb34y272q68ib8741bxk0i6m"; } else if stdenv.system == "i686-linux" then fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/technology/epp/downloads/release/neon/R/eclipse-cpp-neon-R-linux-gtk.tar.gz; sha256 = "0a12qmqq22v7sbmwn1hjv1zcrkmp64bf0ajmdjljhs9ac79mxn5h"; } else throw "Unsupported system: ${stdenv.system}"; }; </del> <ins> ################### Eclipse Scala SDK ################################################################################ </ins> <del> eclipse-sdk-421 = buildEclipse { name = "eclipse-sdk-4.2.1"; description = "Eclipse Classic"; </del> <ins> eclipse-scala-sdk-441 = buildEclipse { name = "eclipse-scala-sdk-4.4.1"; description = "Eclipse IDE for Scala Developers"; </ins> src = if stdenv.system == "x86_64-linux" then <del> fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.2.1-201209141800/eclipse-SDK-4.2.1-linux-gtk-x86_64.tar.gz; sha256 = "1mlyy90lk08lb2971ynglgi3nqvqfq1k70md2kb39jk160wd1xrk"; </del> <ins> fetchurl { # tested url = http://downloads.typesafe.com/scalaide-pack/4.4.1-vfinal-luna-211-20160504/scala-SDK-4.4.1-vfinal-2.11-linux.gtk.x86_64.tar.gz; sha256  = "4c2d1ac68384e12a11a851cf0fc7757aea087eba69329b21d539382a65340d27"; </ins> } else <del> fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.2.1-201209141800/eclipse-SDK-4.2.1-linux-gtk.tar.gz; sha256 = "1av6qm9wkbyk123qqf38f0jq4jv2bj9wp6fmpnl55zg6qr463c1w"; }; }; eclipse_sdk_421 = eclipse-sdk-421; # backward compatibility, added 2016-01-30 eclipse-sdk-422 = buildEclipse { name = "eclipse-sdk-4.2.2"; description = "Eclipse Classic"; sources = { "x86_64-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.2.2-201302041200/eclipse-SDK-4.2.2-linux-gtk-x86_64.tar.gz; sha256 = "0ysa6ymk4h3k1vn59dc909iy197kmx132671kbzfwbim87jmgnqb"; }; "i686-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.2.2-201302041200/eclipse-SDK-4.2.2-linux-gtk.tar.gz; sha256 = "038yibbrcia38wi72qrdl03g7l35mpvl5nxdfdnvpqxrkfffb826"; }; }; }; eclipse_sdk_422 = eclipse-sdk-422; # backward compatibility, added 2016-01-30 eclipse-sdk-431 = buildEclipse { name = "eclipse-sdk-4.3.1"; description = "Eclipse Classic"; sources = { "x86_64-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.3.1-201309111000/eclipse-SDK-4.3.1-linux-gtk-x86_64.tar.gz; sha256 = "0ncm56ylwxw9z8rk8ccgva68c2yr9yrf1kcr1zkgw6p87xh1yczd"; }; "i686-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.3.1-201309111000/eclipse-SDK-4.3.1-linux-gtk.tar.gz; sha256 = "1zxsh838khny7mvl01h28xna6xdh01yi4mvls28zj22v0340lgsg"; </del> <ins> fetchurl { # untested url = http://downloads.typesafe.com/scalaide-pack/4.4.1-vfinal-luna-211-20160504/scala-SDK-4.4.1-vfinal-2.11-linux.gtk.x86.tar.gz; sha256 = "35383cb09567187e14a30c15de9fd9aa0eef99e4bbb342396ce3acd11fb5cbac"; </ins> }; <del> }; </del> }; <del> eclipse_sdk_431 = eclipse-sdk-431; # backward compatibility, added 2016-01-30 eclipse-sdk-44 = buildEclipse { name = "eclipse-sdk-4.4"; description = "Eclipse Classic"; sources = { "x86_64-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.4-201406061215/eclipse-SDK-4.4-linux-gtk-x86_64.tar.gz; sha256 = "14hdkijsjq0hhzi9ijpwjjkhz7wm0pry86l3dniy5snlh3l5bsb2"; }; "i686-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.4-201406061215/eclipse-SDK-4.4-linux-gtk.tar.gz; sha256 = "0hjc4zrsmik6vff851p0a4ydnx99840j2xrx8348kk6h0af8vx6z"; }; }; }; eclipse_sdk_44 = eclipse-sdk-44; # backward compatibility, added 2016-01-30 eclipse-sdk-442 = buildEclipse { name = "eclipse-sdk-4.4.2"; description = "Eclipse Classic"; sources = { "x86_64-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.4.2-201502041700/eclipse-SDK-4.4.2-linux-gtk-x86_64.tar.gz; sha256 = "0g00alsixfaakmn4khr0m9fxvkrbhbg6qqfa27xr6a9np6gzg98l"; }; "i686-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.4.2-201502041700/eclipse-SDK-4.4.2-linux-gtk.tar.gz; sha256 = "1hacyjjwhhxi7r3xyhpqgjqpd5r0irw9bfkalz5s5l6shb0lq4i7"; }; }; }; eclipse_sdk_442 = eclipse-sdk-442; # backward compatibility, added 2016-01-30 </del> <ins> ################### Eclipse SDK ###################################################################################### </ins> <del> eclipse-sdk-45 = buildEclipse { name = "eclipse-sdk-4.5"; description = "Eclipse Mars Classic"; sources = { "x86_64-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5-201506032000/eclipse-SDK-4.5-linux-gtk-x86_64.tar.gz; sha256 = "0vfql4gh263ms8bg7sgn05gnjajplx304cn3nr03jlacgr3pkarf"; }; "i686-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5-201506032000/eclipse-SDK-4.5-linux-gtk.tar.gz; sha256 = "0xv66l6hdlvxpswcqrsh398wg6xhy30f833dr7jvvz45s5437hm3"; }; }; }; eclipse_sdk_45 = eclipse-sdk-45; # backward compatibility, added 2016-01-30 eclipse-sdk-451 = buildEclipse { name = "eclipse-sdk-4.5.1"; description = "Eclipse Mars Classic"; sources = { "x86_64-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.1-201509040015/eclipse-SDK-4.5.1-linux-gtk-x86_64.tar.gz; sha256 = "b56503ab4b86f54e1cdc93084ef8c32fb1eaabc6f6dad9ef636153b14c928e02"; }; "i686-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.1-201509040015/eclipse-SDK-4.5.1-linux-gtk.tar.gz; sha256 = "f2e41da52e138276f8f121fd4d57c3f98839817836b56f8424e99b63c9b1b025"; }; }; }; eclipse_sdk_451 = eclipse-sdk-451; # backward compatibility, added 2016-01-30 eclipse-sdk-452 = buildEclipse { name = "eclipse-sdk-4.5.2"; description = "Eclipse Mars Classic"; sources = { "x86_64-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.2-201602121500/eclipse-SDK-4.5.2-linux-gtk-x86_64.tar.gz; sha256 = "87f82b0c13c245ee20928557dbc4435657d1e029f72d9135683c8d585c69ba8d"; }; "i686-linux" = fetchurl { url = http://www.eclipse.org/downloads/download.php?r=1&nf=1&file=/eclipse/downloads/drops4/R-4.5.2-201602121500/eclipse-SDK-4.5.2-linux-gtk.tar.gz; sha256 = "78f7e537b34333401fc782fbd1260087c586ff93b17b88da5b177642f3aa5a02"; }; }; }; </del> eclipse-sdk-46 = buildEclipse { name = "eclipse-sdk-4.6"; description = "Eclipse Neon Classic";


Question: { stdenv, python3, fetchFromGitHub, fetchpatch }: with python3.pkgs; buildPythonApplication rec { <del> version = "3.8"; </del> <ins> version = "4.1"; </ins> pname = "buku"; src = fetchFromGitHub { owner = "jarun"; repo = "buku"; rev = "v${version}"; <del> sha256 = "0gv26c4rr1akcaiff1nrwil03sv7d58mfxr86pgsw6nwld67ns0r"; </del> <ins> sha256 = "166l1fmpqn4hys4l0ssc4yd590mmav1w62vm9l5ijhjhmlnrzfax"; </ins> }; checkInputs = [

tests pass, while tests fail with: Official Hydra sees the same thing: with their Travis setup. (That is a build of a recent commit, but I still see the same failures after pointing at a checkout of ) Does anyone have any ideas? With nixpkgs master,
See scrapinghub/dateparser, scrapinghub/dateparser and scrapinghub/dateparser.
As long as this problem remains, the best thing to do is using for affected application. Switching to should be done in commits that don't change anything else and that reference this issue in their commit message so that they can easily be reverted. Simply skipping the tests does not make much sense since these are real incompatibilities.


Question: <ins> { lib , stdenv , fetchFromGitHub , pkg-config , fftw , zita-convolver , fftwFloat , libsndfile , ffmpeg , alsa-lib , libao , libmad , ladspaH , libtool , libpulseaudio }: stdenv.mkDerivation rec { pname = "dsp"; version = "1.8"; src = fetchFromGitHub { owner = "bmc0"; repo = "dsp"; rev = "v${version}"; sha256 = "sha256-LTgjpzAGi3oL8l5NcJj1ortKFd3vWDfXHr8YyedAxEE="; }; nativeBuildInputs = [ pkg-config ]; buildInputs = [ fftw zita-convolver fftwFloat libsndfile ffmpeg alsa-lib libao libmad ladspaH libtool libpulseaudio ]; meta = with lib; { homepage = "https://github.com/bmc0/dsp"; description = "An audio processing program with an interactive mode"; license = licenses.isc; maintainers = with maintainers; [ aaronjheng ]; platforms = platforms.linux ++ platforms.darwin; }; } </ins>

Project description is an audio processing program with an interactive mode. Also has a LADSPA frontend. Metadata homepage URL: source URL: license: isc platforms: linux


Question: , buildPythonPackage , fetchPypi , fetchpatch <ins> , stdenv </ins> , sphinx , numpydoc , pytest

Describe the bug fails on Darwin. To Reproduce Steps to reproduce the behavior: Expected behavior Package builds Additional context Error log: <details<summaryError log</summary</detailsMetadata Please run and paste the result. host os: multi-user?: sandbox: version: channels(yl): nixpkgs: Maintainer information: Possibly related to
On the master branch, I removed the derivation from the nix store with and I built it without substitutes; failed with the same message. This is not caused by , but help me discover it due to the update of the requests python package.
maintainer:
I don't have a way to test on joblib for darwin so this is why I didn't have input on this PR. Is there an easy way to test nixpkgs on darwin? Hackintosh via kvm?
There is that works with some tweaking but I wouldn't describe it as easy. Another option is to ask @ GrahamcOfBorg to do the builds on the PR if there are not too many iterations to do.


Question: nixops = super.nixops.overridePythonAttrs ( old: { <ins> postPatch = '' substituteInPlace nixops/args.py --subst-var version ''; </ins> meta = old.meta // { homepage = https://github.com/NixOS/nixops; description = "NixOS cloud provisioning and deployment tool";

The nixopsUnstable version is not set correctly. It should show the version. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --


Question: optionalString config.security.pam.enableEcryptfs '' password optional ${pkgs.ecryptfs}/lib/security/pam_ecryptfs.so '' + <ins> optionalString config.security.pam.enableFscrypt '' password optional ${pkgs.fscrypt-experimental}/lib/security/pam_fscrypt.so '' + </ins> optionalString cfg.pamMount '' password optional ${pkgs.pam_mount}/lib/security/pam_mount.so '' +

I would like to use to encrypt my home directory. is already packaged (as , for some reason) What's missing is the PAM setup (). Given that exists for EcryptFS, I would like to request support for via the option, or something similar. I am aware that EcryptFS is available, to achieve the same goals, however it seems to be considered deprecated by other distributions (, ) and has some which I am not comfortable with.
This is just to say hi and to share that I too am interested in this feature
I marked this as stale due to inactivity. →


Question: ${cfg.extraConfig} ''; qemuConfigFile = pkgs.writeText "qemu.conf" '' <ins> ${optionalString cfg.qemuOvmf '' nvram = ["${pkgs.OVMF}/FV/OVMF_CODE.fd:${pkgs.OVMF}/FV/OVMF_VARS.fd"] ''} </ins> ${cfg.qemuVerbatimConfig} '';

In , I introduced support in libvirtd for UEFI VM creation. rightfully remarked that this brings closure-size up too much. Looking into OVMF shows that only 1MB out of the 114MB install size is needed to enable said UEFI VM creation. I think that we should look into splitting out OVMF_(CODE|VARS) from the rest package.


Question: chown ${bindUser} /var/run/named ''; <del> script = "${pkgs.bind.bin}/sbin/named -u ${bindUser} ${optionalString cfg.ipv4Only "-4"} -c ${cfg.configFile} -f"; </del> <ins> script = "${pkgs.bind.out}/sbin/named -u ${bindUser} ${optionalString cfg.ipv4Only "-4"} -c ${cfg.configFile} -f"; </ins> unitConfig.Documentation = "man:named(8)"; }; };

The symlinking between the multiple outputs of seems to prevent it from installing. I was looking to install it to have the dig command available. - System: 17.03pre94050. (Gorilla) Nix version: nix-env (Nix) 1.11.4 Nixpkgs version: "17.03pre94050."
11.4 still doesn't contain :-( How could we have that as default in 16.09? I consider it quite an important feature for + multiple outputs. would you be against porting that PR to 1.11.5 and making that default in 16.09 and master?
+1 for a 1.11.5 Nix release in general :)
Since this seems to be an issue for multiple packages, I am raising the severity on here.
Looks like the same kind of issue as So +1 for Nix 1.11.5 on NixOS 16.09, if that's what it takes to fix this.
ping again about nix-1.11.5 (my comment above).


Question: , gnome , gtksourceview4 , gjs <del> , webkitgtk_4_1 </del> <ins> , libsoup , webkitgtk </ins> , icu , wrapGAppsHook , gst_all_1

Describe the bug When I try to preview videos like .mp4 or webm in Nautilus using Sushi, it says "Your GStreamer installation is missing a plug-in". To Reproduce Steps to reproduce the behavior: NixOS with Gnome3 desktop space on a video file in Nautilus Additional context It's possible that there's some configuration in my homedir that makes it break, since I have the same homedir that I had under other Linux installs, not sure how to find it however. outputs Notify maintainers maybe? Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(wmertens): channels(root): nixpkgs: Maintainer information:
Would need to add here, I think.
that makes sense - it seems like I would like the bad and the ugly too. How about a nixpkgs configuration setting that decides which plugin sets to load, and having plugins-base include them? That should make it backwards-compatible.
Most of them depend on base so that would be a dependency cycle. Also we would need to move the wrappers into a separate derivation or we would have to rebuild everything. Alternately, you can set environment variable (I believe some NixOS module does that). Not a fan but it should work provided some ABI break does not sneak in.
I marked this as stale due to inactivity. →
Still a problem
I marked this as stale due to inactivity. →
if sushi is not a dependent of any package then why would we have to rebuild everything? What do you mean by everything? Perhaps until a separate wrapper derivation is composed we can add a configuration option to the nixos module that would add these gstreamer to it if needed. Also, doesn't work at all for me nowadays, I think since Gnome 41.
I was replying to Wout’s question above regarding a general solution pulling extra plug-ins into gst-plugins-base. For now, I would be fine with adding everything unconditionally to sushi as mentioned in I must have forgotten to test it during the update when I removed libmusicbrainz but forgot to add libsoup: Could you try


Question: }; security.pam.enableEcryptfs = mkEnableOption (lib.mdDoc "eCryptfs PAM module (mounting ecryptfs home directory on login)"); <ins> security.pam.enableFscrypt = mkEnableOption (lib.mdDoc '' Enables fscrypt to automatically unlock directories with the user's login password. This also enables a service at security.pam.services.fscrypt which is used by fscrypt to verify the user's password when setting up a new protector. If you use something other than pam_unix to verify user passwords, please remember to adjust this PAM service. ''); </ins> users.motd = mkOption { default = null;


Question: linkFarm "zig-packages" [ { <del> name = "122014eeb4600a059bdcfe1c864862f17e6d5e4237e3bb7d6818f2a5583f6f4eb843"; </del> <ins> name = "1220687c8c47a48ba285d26a05600f8700d37fc637e223ced3aa8324f3650bf52242"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-pixman/archive/v0.1.0.tar.gz"; hash = "sha256-Atfkiyt9v+GWry3xA2Y0Iv6AvwbZ+EHfHLmX0AUEz6Y="; </del> <ins> url = "https://codeberg.org/ifreund/zig-wayland/archive/v0.2.0.tar.gz"; hash = "sha256-dvit+yvc0MnipqWjxJdfIsA6fJaJZOaIpx4w4woCxbE="; </ins> }; } { <del> name = "1220714d1cc39c3abb1d9c22a0b838d847ead099cb7d9931821490483f30c022e827"; </del> <ins> name = "12209db20ce873af176138b76632931def33a10539387cba745db72933c43d274d56"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-wlroots/archive/v0.17.0.tar.gz"; hash = "sha256-C1D2dBn65Z9PmDacpeYbdX574fcOyYi/BJVDUMibkPA="; </del> <ins> url = "https://codeberg.org/ifreund/zig-pixman/archive/v0.2.0.tar.gz"; hash = "sha256-zcfZEMnipWDPuptl9UN0PoaJDjy2EHc7Wwi4GQq3hkY="; </ins> }; } { <del> name = "1220840390382c88caf9b0887f6cebbba3a7d05960b8b2ee6d80567b2950b71e5017"; </del> <ins> name = "1220c65ab884c236cc950b564c70f6cd04046d86485ee76e0cde886cef7438021b4f"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-xkbcommon/archive/v0.1.0.tar.gz"; hash = "sha256-xilmsDGWlkfpTiGff+/nb76jx87ANdr4zqYy6rKOBMg="; </del> <ins> url = "https://codeberg.org/ifreund/zig-wlroots/archive/v0.17.1.tar.gz"; hash = "sha256-rVI/tJD3cx8b+nGTG5u08/RYoI179oDY7AY0riTntA0="; </ins> }; } { <del> name = "1220b0f8f822c1625af7aae4cb3ab2c4ec1a4c0e99ef32867b2a8d88bb070b3e7f6d"; </del> <ins> name = "1220c90b2228d65fd8427a837d31b0add83e9fade1dcfa539bb56fd06f1f8461605f"; </ins> path = fetchzip { <del> url = "https://codeberg.org/ifreund/zig-wayland/archive/v0.1.0.tar.gz"; hash = "sha256-VLEx8nRgmJZWgLNBRqrR7bZEkW0m5HTRv984HKwoIfA="; </del> <ins> url = "https://codeberg.org/ifreund/zig-xkbcommon/archive/v0.2.0.tar.gz"; hash = "sha256-T+EZiStBfmxFUjaX05WhYkFJ8tRok/UQtpc9QY9NxZk="; </ins> }; } ]

Package name: river Latest released version: 0.3.3 <!-- Search your package here: --- Current version on the unstable channel: 0.3.2 Current version on the stable/release channel: 0.3.2 <!-- 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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
3 is only a zig 0.13 compatibility release. It’s blocked by
has been merged, this is not blocked anymore.


Question: <del> { lib , stdenv , git , git-lfs , fetchurl , wrapGAppsHook3 , alsa-lib , at-spi2-atk , cairo , cups , dbus , expat , gdk-pixbuf , glib , gtk3 , mesa , nss , nspr , xorg , libdrm , libsecret , libxkbcommon , pango , systemd , hunspellDicts , useHunspell ? true , languages ? [ "en_US" ] , withNemoAction ? true , makeDesktopItem , copyDesktopItems , asar , python3 }: let pname = "pulsar"; version = "1.114.0"; sourcesPath = { x86_64-linux.tarname = "Linux.${pname}-${version}.tar.gz"; x86_64-linux.hash = "sha256-O//dowoMgQfS3hq088IKr5aJd5St9zpT/ypfuswnyv0="; aarch64-linux.tarname = "ARM.Linux.${pname}-${version}-arm64.tar.gz"; aarch64-linux.hash = "sha256-EzCTB1Ib9cTbslEdXPsS5gehHr1qd5v4iZgOqpxhUmA="; }.${stdenv.hostPlatform.system} or (throw "Unsupported system: ${stdenv.hostPlatform.system}"); newLibpath = lib.makeLibraryPath [ alsa-lib at-spi2-atk cairo cups dbus expat gdk-pixbuf glib gtk3 libsecret mesa nss nspr libdrm xorg.libX11 xorg.libxcb xorg.libXcomposite xorg.libXdamage xorg.libXext xorg.libXfixes xorg.libXrandr xorg.libxshmfence libxkbcommon xorg.libxkbfile pango stdenv.cc.cc.lib systemd ]; # Hunspell hunspellDirs = builtins.map (lang: "${hunspellDicts.${lang}}/share/hunspell") languages; hunspellTargetDirs = "$out/opt/Pulsar/resources/app.asar.unpacked/node_modules/spellchecker/vendor/hunspell_dictionaries"; hunspellCopyCommands = lib.concatMapStringsSep "n" (lang: "cp -r ${lang}/* ${hunspellTargetDirs};") hunspellDirs; in stdenv.mkDerivation rec { inherit pname version; src = with sourcesPath; fetchurl { url = "https://github.com/pulsar-edit/pulsar/releases/download/v${version}/${tarname}"; inherit hash; }; patches = [ ./001-patch-wrapper.patch ]; nativeBuildInputs = [ wrapGAppsHook3 copyDesktopItems asar ]; buildInputs = [ gtk3 xorg.libxkbfile ]; dontBuild = true; dontConfigure = true; installPhase = '' runHook preInstall mkdir -p $out/opt/Pulsar mv * $out/opt/Pulsar runHook postInstall ''; preFixup = '' gappsWrapperArgs+=( # needed for gio executable to be able to delete files --prefix "PATH" : "${lib.makeBinPath [ glib ]}" ) '' + lib.optionalString useHunspell '' # On all platforms, we must inject our dictionnaries ${hunspellCopyCommands} ''; postFixup = '' opt=$out/opt/Pulsar # Patch the prebuilt binaries patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${newLibpath}:$opt"  --add-needed libffmpeg.so  --add-needed libxshmfence.so.1  --add-needed libxkbcommon.so.0  --add-needed libxkbfile.so.1  --add-needed libsecret-1.so.0  $opt/pulsar patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  --set-rpath "${newLibpath}"  $opt/resources/app/ppm/bin/node patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)"  $opt/resources/app.asar.unpacked/node_modules/symbol-provider-ctags/vendor/ctags-linux # Replace the bundled git with the one from nixpkgs dugite=$opt/resources/app.asar.unpacked/node_modules/dugite rm -f $dugite/git/bin/git ln -s ${git}/bin/git $dugite/git/bin/git # Not only do we need to replace the git binary itself, we also need to replace # all the symlinks in dugite/git/libexec/git-core. for file in "$dugite/git/libexec/git-core"/*; do if [ -x "$file" ] && file "$file" | grep -q "ELF"; then # Remove ELF executable rm "$file" # Get the corresponding filename in nixpkgs's git filename=$(basename "$file") git_executable="${git}/libexec/git-core/$filename" # Create symlink to $git_executable ln -s "$git_executable" "$file" echo "Replaced $file with symlink to $git_executable" fi done # Was symlinked in previous loop, but actually, nixpkgs has a separate package for git-lfs # Unlink to avoid a "File exists" error and relink correctly unlink $dugite/git/libexec/git-core/git-lfs ln -s ${git-lfs}/bin/git-lfs $dugite/git/libexec/git-core/git-lfs '' + lib.optionalString (stdenv.hostPlatform.system == "x86_64-linux") '' # We have to patch a prebuilt binary in the asar archive # But asar complains because the node_gyp unpacked dependency uses a prebuilt Python3 itself rm $opt/resources/app.asar.unpacked/node_modules/tree-sitter-bash/build/node_gyp_bins/python3 ln -s ${python3.interpreter} $opt/resources/app.asar.unpacked/node_modules/tree-sitter-bash/build/node_gyp_bins/python3 '' + '' # Patch the bundled node executables find $opt -name "*.node" -exec patchelf --set-rpath "${newLibpath}:$opt" {} ; # Also patch the node executable for apm patchelf --set-rpath "${newLibpath}:$opt" $opt/resources/app/ppm/bin/node # The pre-packaged ASAR bundle comes with prebuild binaries, expecting libstdc++.so.6 asarBundle=$TMPDIR/asarbundle asar e $opt/resources/app.asar $asarBundle find $asarBundle -name "*.node" -exec patchelf --set-rpath "${newLibpath}:$opt" --add-needed libstdc++.so.6 {} ; unlink $asarBundle/node_modules/document-register-element/dre # Self referencing symlink, breaking asar rebundling asar p $asarBundle $opt/resources/app.asar rm -rf $asarBundle # We have patched the original wrapper, but now it needs the "PULSAR_PATH" env var mkdir -p $out/bin wrapProgram $opt/resources/pulsar.sh  --prefix "PULSAR_PATH" : "$opt/pulsar" ln -s $opt/resources/pulsar.sh $out/bin/pulsar ln -s $opt/resources/app/ppm/bin/apm $out/bin/ppm # Copy the icons mkdir -p $out/share/icons/hicolor/scalable/apps $out/share/icons/hicolor/1024x1024/apps cp $opt/resources/pulsar.svg $out/share/icons/hicolor/scalable/apps/pulsar.svg cp $opt/resources/pulsar.png $out/share/icons/hicolor/1024x1024/apps/pulsar.png '' + lib.optionalString withNemoAction '' # Copy the nemo action file mkdir -p $out/share/nemo/actions cp ${./pulsar.nemo_action} $out/share/nemo/actions/pulsar.nemo_action ''; desktopItems = [ (makeDesktopItem { name = "Pulsar"; desktopName = "Pulsar"; exec = "pulsar"; icon = "pulsar"; comment = "A Community-led Hyper-Hackable Text Editor"; genericName = "Text Editor"; categories = [ "Development" "TextEditor" "Utility" ]; mimeTypes = [ "text/plain" ]; }) ]; passthru.updateScript = ./update.mjs; meta = with lib; { description = "A Community-led Hyper-Hackable Text Editor"; longDescription = '' A Community-led Hyper-Hackable Text Editor, Forked from Atom, built on Electron. Designed to be deeply customizable, but still approachable using the default configuration. ''; homepage = "https://github.com/pulsar-edit/pulsar"; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; license = licenses.mit; platforms = platforms.linux; maintainers = with maintainers; [ bryango ]; knownVulnerabilities = [ "CVE-2023-5217" "CVE-2022-21718" "CVE-2022-29247" "CVE-2022-29257" "CVE-2022-36077" "CVE-2023-29198" "CVE-2023-39956" ]; }; } </del>

Package name: pulsar Latest released version: 1.117.0 Current version on the unstable channel: 1.114.0 Current version on the stable/release channel: 1.117.0 Notify maintainers


Question: patchPhase = ''patchShebangs . '' + stdenv.lib.optionalString stdenv.isDarwin '' sed -i 's/#ifndef __MAC_10_11/#if 1/' ./libavcodec/audiotoolboxdec.c <ins> '' + stdenv.lib.optionalString (frei0r != null) '' substituteInPlace libavfilter/vf_frei0r.c  --replace /usr/local/lib/frei0r-1 ${frei0r}/lib/frei0r-1 substituteInPlace doc/filters.texi  --replace /usr/local/lib/frei0r-1 ${frei0r}/lib/frei0r-1 </ins> ''; configureFlags = [

When using filters, look for them in and co. Instead it should look for it in for example. Setting the environment variable can work around that issue: . But it would be nice to have it work out of the box. Result: System: 17.03.1556. (Gorilla)


Question: inherit pname version; inherit src; <del> npmDepsHash = "sha256-+pr9fWg/9kxkYMmthtqhjgF6MOomSQxVCO5V8tHHRdE="; </del> <ins> npmDepsHash = "sha256-7oh5bl5APAvzb/TxHMUP/saRWLwuP9xqGvn7/RDhFk8="; </ins> npmFlags = [ "--legacy-peer-deps" ]; makeCacheWritable = true;

Package name: feishin Latest released version: 0.7.1 <!-- Search your package here: --- Current version on the unstable channel: 0.6.1 Current version on the stable/release channel: 0.5.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. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
thanks for reporting this, just noticed I hadn't subscribed to release notifications. Shouldn't miss any from now on :) Fixed by (awaiting review).


Question: qtdeclarative = [ ./qtdeclarative.patch ]; qtscript = [ ./qtscript.patch ]; qtserialport = [ ./qtserialport.patch ]; <del> qtwebengine = [ ] </del> <ins> qtwebengine = [ # Fix build with bison-3.7: https://code.qt.io/cgit/qt/qtwebengine-chromium.git/commit/?id=1a53f599 (fetchpatch { name = "qtwebengine-bison-3.7-build.patch"; url = "https://code.qt.io/cgit/qt/qtwebengine-chromium.git/patch/?id=1a53f599"; sha256 = "1nqpyn5fq37q7i9nasag6i14lnz0d7sld5ikqhlm8qwq9d7gbmjy"; stripLen = 1; extraPrefix = "src/3rdparty/"; }) ] </ins> ++ optional stdenv.isDarwin ./qtwebengine-darwin-no-platform-check.patch; qtwebkit = [ (fetchpatch {

Describe the bug qtwebengine fails just after successfully configuring with error message To Reproduce ` Expected behavior should compile Notify maintainers Metadata
Pull request works on my machine. Thx.


Question: , pango , pulseaudio , python3 <ins> , stdenv </ins> , util-linux , which , x264 , x265 , xauth <ins> , xdg-utils </ins> , xorg , xorgserver }:

Xpra supports forwarding invocations from the server to the client. The Xpra client defaults to hardcoding as the command to invoke on the client, which does not exist in NixOS. This bug does not impact hosts other than NixOS. Steps to reproduce the behavior: somehow. The Xpra client should invoke the local . N/A. This could be fixed by setting the open command to just , but it might match the intent better to change it to something like perhaps. Presumably, the point of doing it this way is to avoid any other copies of that might appear on the , e.g. Xpra's own. I suppose we can't really rely on to exist: even if we could on NixOS, we can't on other Linux distributions running Nix, where might make more sense. It seems to me that the best compromise, then, is to hardcode a path to copy of and users can override this using the option if needed. The open command that Xpra uses is configurable on the client-side, but the default is set as a platform-specific variable. On Linux, it is set in . Because there are separate values for both Windows and Darwin hosts, patching the value to shouldn't ever break them (but of course it should still be a Linux-specific patch, otherwise it unnecessarily brings into the closure.) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

Julia 1.5 is out, see: and we don't have it packaged. More over, see how defines our other Julias: Several issues: is pointing to a TLS version which is old IMO. Certainly there are breaking changes seen in , but since Nixpkgs is a somewhat rolling release distro, are we going to keep these older versions and default to them for ever? I've once tried to reach for the community to hear if there's a strict policy regarding such scenarios, but Anyway, I'd like to propose a change that will keep only the LTS version and the latest - currently 1.4, and perhaps make the attribute , point to the latest. Any thoughts from maintainers or users? cc
Also, now I noticed all of our Julias fail to build, e.g:
I agree. And the 1.5 release candidates are out, so this will become the latest version in the near future. Last time I looked, the package built the same deps for all versions, including 0.7. In versions 1.0 and later, there are actually fewer dependencies (e.g. arpack and fftw have been dropped), so the package should be cleaned up to not include these unnecessary libraries in the build. I also think the default version should be the latest version (i.e., unless somebody explicitly installs julia-1-lts, they should get the latest).
OK I'm glad I have your support. I'll let this issue stay open for a while and hopefully I'll be able to take care of this a month or so from now.
cc
Back when Julia tests were not so messed up, I think there was often 1 previous version. I guess with 1.3 needing overriding to no tests, it is fine to just have julia-1-lts and Julia 1.4 as julia once Julia 1.4 gets built fine with some tests.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Haven't had a lot of time to work on julia in nixpkgs, so just posting this as a FYI.


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

We used multiple versions of julia at work, but we use a custom derivation, similar to this: We also do not run the tests, but in general it has been working great. Previously we also used the binary builds patched with patchelf, as there were some differences in the structure of the results of the vanilla binary build provided by julia and what we got when building from source. We gave up on using 'system' libraries, and build the releases that julia provides, as julia is very specific in the versions for its dependencies (LLVM patches mostly).
I tried to use that tarball in order to write a derivation from scratch. Here's my attempt: It fails with: Naturally I didn't further attempt to add curl or wget to the inputs, as that would fail in a sandbox as well. I've opened an issue upstream: complaining that that tarball doesn't really contain all dependencies.
I ran with sandbox enabled, and the expression I linked with works for me. So I think it is fine to just add curl to the deps, as with the full tarball, it isn't actually used.
There is another approach to avoid running tests: using precompiled binary. I tried downloading the 1.4.2 binary from and then afterward ran on the binary, then I got a running Julia interpreter just like that.
We did the same for a while using code similar to this: Unfortunately, we actually sometimes need to patch Julia, so we switched to the julia expressions from source, that I posted earlier.
Thanks that expression works well thanks to . I'm testing it now.
OK so after a long build, I got a working Julia derivation with these references: And this closure size: Which I must say it is satisfying. The question is, is this how we'd want it to be built? Using all of their dependencies and practically non of ours? Some of their dependencies are required to be patched, according to and they also specify that using the OS' libraries is not officially supported? Anyway I'd happy to get help on deciding this.
does this lead to Julia tests passing? I think for every dependency they patch, it is OK to just use their patched version. I guess it could be nice to use a separate build unpatched (but using the exact same version sounds like a likely restriction), but whatever dependency does not work right away can be switched to bundled.


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

I think it did, I've set and the build passed but I haven't inspected the log much, but here it is: Currently produces this log but there's no PR yet as I think there are many makeFlags that should probably be set as well. If anyone feels confident to open a PR with this feel free to ping me for a review. I agree with the idea, but what's bothering me is that it's not absolutely clear what versions are patched and which are not - the docs vs what's actually found in is not totally inline. Also, it seems that some of the patches are old, and were suggested upstream (to the libraries) but they weren't merged there for some reason. I'm still investigating, See My current target is to decide what libraries to use our version vs their version, with the preference to use our version, in order to hopefully reduce closure size due to sharing shared libraries. The idea is to decide this by checking whether the libraries have included the patch Julia suggests, and then whether the library's maintainer has released a new version that includes Julia's maintainers' patch, and whether we ship that new version.
does this lead to Julia tests passing? I think this log is cut short before the interesting part…
I've uploaded it here:
Hmmm. Reading the log does not convince me the tests were run… Pity.
Since 1.5 was just released, the title should probably be updated to be 1.5.
Downside with the patching approach, is users lose the ability to compile against MKL, which has HUGE performance increase (last I saw showed that MKL was ~4x faster at matrix multiplication!!). Would need to also package JuliaPro to get MKL. Of course, anything working nothing working, although would be a shame to lose compilation options.
Says
Thanks garrison, I saw that, but I have a feeling it won't play nicely with Nix...although if we go patching route, perhaps could do that during buildPhase
Are you concerned about specifically or all packages that use BinaryBuilder? There are a lot of them. More on this at
As I understand binary builder, that all happens in userspace, but modifies , which is in /nix/store
The installation instructions for do not seem to require root. My guess is that it stores the modified sysimage somewhere in .


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

Am I wrong?
I just tried it with Julia 1.4 installed with Nix, and as I suspected fails to build due to
We need to have a interface - that would support building binary packages, and make the interpreter aware of them. I wish I was a bit more motivated to do this, but upstream disappoints me regarding the humble task of compiling Julia as is, with the right selection of a few system dependencies - no response at all at & . I'm also dis-motivated to explore this aspect, since their build system is of plain makefiles, and they keep patches of dependencies from so long ago, without documenting whether they are needed / used or not...
Nix behind It is a shame to see julia's support in NixOS languish. It seems pretty clear to me that upstream is only interested in supporting the configuration obtained by cloning their repository and typing on a stock Linux distribution. I understand their perspective in many ways, as having julia and all of its packages "just work" requires a lot of care, and building with unsupported configurations is very likely to result in brokenness somewhere in the package ecosystem if not in julia itself. Julia is a bit special in this regard because of its emphasis on performance and also its need to support interfaces to other languages/frameworks that often have weird requirements. I have found that typically, there is very good reason for these patches, even though at times they may not be documented except in git and github history. (Admittedly, I am less involved in upstream than I used to be.)
I think Julia team initially evaluated Nix as their binary distributor () but decided against it—there was a discussion somewhere but can’t find it. IIRC lack of Windows / desire to tie into native pkg management systems were factors. Julia’s does a pretty great job, and uses a solver to properly resolve dependency versions based on constraints. I’ve been incredibly frustrated by the withPackages pattern, at least in python. I constantly run into problems due to nixpkgs ignoring version constraints. There are some other nice advantages to nix of course: binary dependencies are shared across language ecosystems for example, and there are lots of supremely annoying packages (I’m looking at you CUDA...) that Nix makes delightfully easy to install, use, and maintain parallel versions.


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

But until Nixpkgs supports multiple versions across the board, and has a solver baked in, I’m honestly not sure Nix brings enough advantages to bail on Edit: I think the approach done by poetry2nix and Mach-nix are the way to go for Julia packages + nix. yarn2nix is another shining example. I would love to see a solution in this vein—didn’t mean to douse any enthusiasm for people interested in helping improve the Julia situation on NixOS :)
Maybe it is worth to reaching out to Julia Computing folks at to get their attention on ?
We'd probably need to put this information in our attribute sets, just like our Python packages know what deps they need. Hmm that's a bit surprising to hear as the Python ecosystem seems most well organized. Have you ever encountered a real bug with a mismatched version of a dependency with a specific version specified in a package's ? IIRC fails if a version is used and it's not exactly what's available. If you've ever felt there's a certain python package of a certain version missing, have you considered contributing it? Even if not, was it too hard to override it? What do you mean "across the board"? That might be much more harder then it sounds, due to the constraints of Nix it self when being evaluated everytime you run and friends, see It's not a question of whether Nix brings an advantage or not, it's a question of whether there are any Julia packages that are built at other distros imperatively with a , and this produces (or even worse, downloads) shared objects or executables into (not in ), linked to Julia or other Nix deps that do reside in . If the answer is yes, than every Nix user will experience breakage after Julia is updated in his - not necessarily if it's a version bump of Julia, it could be a mere rebuild of Julia by hydra. Yea Mach-nix is an awesome idea well implemented ( thanks for the inspiration :heart:). I've also reached a similar conclusion at . However, this is my opinion for Rust and Go, and I tend to think that for a small ecosystem like Julia, perhaps it'll be too much - it shouldn't be that hard to manage all of these pacakges like Python is managed in Nixpkgs.
I opened
Frequently.


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

Especially with Scipy, matplotlib, bokeh, sklearn, tensorflow, pytorch, etc... Often, nixpkgs used to have it until it was updated. Except in very rare circumstances, we do not keep more than one version of a python package around. I have no interest wasting time working around bugs that authors tried to spare me by specifying precise versions. It seems a sort of cognitive dissonance in our next community that we all care so deeply about reproducible builds, but for convenience often disregard the officially supported dependencies. As a result, there are often subtle bugs in software on NixOS that do not appear on other platforms. (Eg x11vnc crashes, shared memory problems, etc). Nix supports crazy high specificity in versioning, well we past semantic versioning down the the bit in many cases. And yet in nixpkgs, by convention, we remove the old version anytime we update. It’s understandable that Hydra cannot build everything, but it’s always bothered me that I have to pin nixpkgs if I want a build to stay functional over 1+ years. is mostly declarative. Of course, Julia is constantly re-compiling code, and until there is true support for precompilation, I don’t see how it’s possible to use nix store. This is due to multiple dispatch. Suppose I wrote a library to do an efficient k-nearest-neighbor query using some fancy free structure. Perhaps the core algorithms simply require a function for your types. When you write this new function, Julia has to compile all the code in the k-nearest neighbor library for this new type. Thus, it is not possible right now to compile a package on its own as the core pattern in Julia involves extending the function of other packages via multiple dispatch. You can only compile a package in context of the code that is running. Therefore, the Nix store approach is not appropriate. See
I see. You are talking about "authors" of Nixpkgs' expressions? I'm still a bit perplexed, as I earlier said, and correct me if I'm wrong: should fail if is used in , and the exact version is not available. Sometimes (), we do hardcode such version requirement changes in our expressions, but hopefully that's done only when it's justified.


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

I agree (maybe a bit ). Generally I think, every dep's version related issue should be handled by someone like you, who's familiar with python packages you use. I'd at least (open PRs) to fix the issues I encounter :). I see. I guess the situation is more complex than I thought, but I don't think I'd be able to form a strong opinion until I'll get a Julia interpreter from an expression I'm satisfied with. Thanks for the link :).
Unfortunately, this pattern is done constantly (including in my own contributions!). The problem is that, except an extremely rare cases like tensorflow, nixpkgs does not allow multiple versions of same python package to co-exist. Every time we update a package, we remove the previous version from nixpkgs. Confounding this issue, we often disable tests because sometimes the effort is just too high when developers bake in assumptions that aren’t compatible with the Nix ethos (for some reason this seems to happen more with tests then source code...). The most frequent cause of failure is the code needs to download something to run the test. (I’ve tried to lobby in the past that the test phase should be permitted to have Internet access as long as it doesn’t modify /nix/store, but I digress). In any case, the end result is that using a python package on Nix typically means you aren’t using the exact dependencies that upstream declared, and you’re more likely to have a package that despite having changes in dependencies has never had the test run. Thus, amazingly, I’ve had more luck with Julia packages working on NixOS than Python when all other binaries are present in environment.
I don't think there's a strong policy in our Python ecosystem against multiple versions of packages - if this is what upstream recommends. Anyway, the whole topic is out of scope for this issue. Feel free to open a new issue and cc me and who's working hard to ship a 20.09 release.
Yes, sorry getting a little off topic here. I mainly mention it to suggest that our efforts in Julia that start from scratch Can learn from these issues. I’m not too familiar with the new binary builder, but was quite nice in that it would first search for libraries before attempting to install.


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

See this issue for some context: Note that a core Julia dev gave a pretty great endorsement on Nix (albeit back in 2014): I think it might be most productive to do this development outside of nixpkgs, and do it in Julia to hook in with nixpkgs as needed. That way users could seamlessly use Pkg in Julia. I’d love to and have it just work instead of the current hack that I wrote that a lot of people seem to be using ()
Short summary of the Discourse thread: for LLVM and libuv it is essential to use the patches/forks. For other packages it is probably unnecessary to use the exact version specified by upstream.
Thanks for being there with me :). I think I'm gonna work on this once we are through with , to avoid merge conflicts.
TIL Guix manages to package Julia 1.4.1: What's interesting, is that they but they build it with Julia's LLVM patches fetched from the internet - they don't rely on Julia's build system to build it's own LLVM. For similar dependencies which the real system's version can't be used, they do the same. I think we should try to copy this approach.
FWIW I did that in Fedora originally, but I stopped. Since LLVM makes breaking releases very quickly, you'll probably want to move to a new version that Julia doesn't support quite soon.
Maybe I don't understand, but why should I move to an LLVM version that julia doesn't support? Also, aren't the and versions don't introduce breaking changes between minor releases? We could stick to since that's what Guix does and I think Julia uses this version as a base too.
I don't really know how NixOS works, hence the "FWIW". If you used versioned LLVM packages and keep older major versions then it's probably OK.
Just offering a user perspective: Julia provides a package manager that provides mostly reproducible (in a practical/scientific reproducibility sense rather than a bit-identical sense) environments easily from manifests. Increasingly, these environments are isolated from the host OS by binary packages for dependencies being served by Julia. I don't want Nix to manage dependencies that can handle for me: Julia already handles those excellently and conveniently. I just want Nix to handle the (usually few) system dependencies.


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

What I would like as a NixOS user is for Nix to provide me with a working Julia 1.5 derivation that provides: julia, a FHS wrapper or something providing compatible versions of the few things that Julia's binary packages need (just libc, libstdc++, libgfortran; I think. ). When I say "compatible", I mean that these libraries should work with the binaries and with the julia binary provided by Nix. Not all Julia packages are BinaryBuilder-ised yet, so I'd also want an easy way to specify that I want compatible versions of other packages installed (e.g. Qt, cairo, etc). For packages that need python, I don't know if I'd like Julia or Nix to handle installing and managing that. The simplest approach would be to tell Julia to do it (there is pretty good support in Julia for distributing isolated environments of python + packages + dependencies; better than in , imo). I don't know how doable any of that is in Nix, just describing what a good outcome would look like to me.
I think this is quite doable. I would propose that we add a new package, , that is a "batteries included" build that contains system libraries for all common Julia packages. Would this approach work for BinaryBuilder? I haven't used this yet. If not, we could fall back to a FHSuserenv, but I'm reluctant to do so if at all avoidable as there are outstanding nix bugs () that create seg faults in some heavy data processing workflows.
I think that is a good proposal and I think it will work with BinaryBuilder packages (e.g. SDL2_jll). In any case, some approach that works with BinaryBuilder packages should be found because those are a critical part of the Julia environment now :) Some important packages (e.g. GR) still want to build and install their own software dynamically, and that doesn't work well in Nix, but most of those can plausibly move to the BinaryBuilder system (PR for GR ), so I think letting those be broken would be tolerable (and a big improvement over the status quo of Julia on nix). Perhaps we can get something working quickly by just patchelf'ing the official Julia builds for now? (I don't understand how all of this stuff works!)


Question: enableParallelBuilding = true; <del> doCheck = !stdenv.isDarwin; </del> <ins> # Other versions of Julia pass the tests, but we are not sure why these fail. doCheck = false; </ins> checkTarget = "testall"; # Julia's tests require read/write access to $HOME preCheck = ''

Is there anything presently blocking just getting julia 1.5 into nixpkgs? I don't care about ecosystem working with nixpkgs, just a good ol' fashioned julia install.
yes, see
If you just want Julia and don't mind about binary packages breaking you can just download Julia from the official site and patchelf it. On Sun, 4 Oct 2020, 09:32 Tyler Benster, <:
On the there was also the idea floated to patch to patchelf dynamically loaded binary dependencies.
Guix has a Julia package and it works quite well. Perhaps some ideas can be borrowed from there: It'd be really useful to get Julia working on Nix. It's the only big outstanding thing that doesn't work and prevents me from migrating some servers in my organization.
I tried to copy their expressions in and it doesn't work yet, but there's also another seemingly working attempt by at .
So, do we want anything else now that 1.5.3 is packaged (:greenheart: ? I think we: 't need clean up the expressions a bit - not use the file if it's not shared. I did (2) along with the julia_10 fix in As for (1) I will need a bit of feedback.
I guess some people like me still use julia_13 via test-disabling overrides, so a bit of time after 1.5 reaches channels for smooth transition could make sense?
Maybe backport 1.5 to 20.09?
OK so I disabled the tests for julia13 in and made the default there as well. All merged pull requests referenced here should be backported.


Question: my $kernel = copyToKernelsDir(Cwd::abs_path("$path/kernel")); my $initrd = copyToKernelsDir(Cwd::abs_path("$path/initrd")); <del> if ($extraInitrd) { $initrd .= " " .$extraInitrdPath->path; </del> <ins> # Include second initrd with secrets if ($initrdSecrets) { # Get last element of path $initrd =~ //([^/]+)$/; my $initrdSecretsPath = "$bootPath/kernels/$1-secrets"; $initrd .= " $initrd-secrets"; my $oldUmask = umask; # Make sure initrd is not world readable (won't work if /boot is FAT) umask 0137; my $initrdSecretsPathTemp = File::Temp::mktemp("$initrdSecretsPath.XXXXXXXX"); system("$path/append-initrd-secrets", $initrdSecretsPathTemp) == 0 or die "failed to create initrd secretsn"; rename $initrdSecretsPathTemp, $initrdSecretsPath or die "failed to move initrd secrets into placen"; umask $oldUmask; $copied{$initrdSecretsPath} = 1; </ins> } my $xen = -e "$path/xen.gz" ? copyToKernelsDir(Cwd::abs_path("$path/xen.gz")) : undef; # FIXME: $confName

Ditto. I have noticed this accidentially whily working at . Nixpkgs version: (run ) cc
You can puts secrets in an additionnal initrd readable by root only, and use See
There is more generic option now, . We probably want to merge those.


Question: <del> { lib, stdenv, fetchurl, makeWrapper, jre, ncurses }: stdenv.mkDerivation rec { version = "3.1.0"; pname = "dotty-bare"; src = fetchurl { url = "https://github.com/lampepfl/dotty/releases/download/${version}/scala3-${version}.tar.gz"; sha256 = "9bsZ2FtIb6AvA3W3r2Vv0dPNicuYjMBz3X48z45Avv8="; }; propagatedBuildInputs = [ jre ncurses.dev ] ; nativeBuildInputs = [ makeWrapper ]; installPhase = '' mkdir -p $out mv * $out ''; fixupPhase = '' bin_files=$(find $out/bin -type f ! -name common) for f in $bin_files ; do wrapProgram $f --set JAVA_HOME ${jre} --prefix PATH : '${ncurses.dev}/bin' done ''; meta = with lib; { description = "Research platform for new language concepts and compiler technologies for Scala"; longDescription = '' Dotty is a platform to try out new language concepts and compiler technologies for Scala. The focus is mainly on simplification. We remove extraneous syntax (e.g. no XML literals), and try to boil down Scala’s types into a smaller set of more fundamental constructs. The theory behind these constructs is researched in DOT, a calculus for dependent object types. ''; homepage = "http://dotty.epfl.ch/"; license = licenses.bsd3; platforms = platforms.all; maintainers = [maintainers.karolchmist maintainers.virusdave]; }; } </del>

Project description Scala 3 is more than a year old. It would be nice to have it packaged in nixpkgs as well. Maybe it is, but I couldn't find it under "scala-3" or respective versions. Metadata homepage URL: https://scala- source URL: license: Apache-2.0 License platforms: unix, linux, darwin, ...
is already packaged.
Indeed: the Scala 3 compiler started out under the codename 'dotty', and that's how it was packaged initially in nixpkgs. Now that dotty has become the 'official' scala 3 compiler (see also ), we should probably rename the package to as well? /cc
Feel free to update, rename and alias the old name :) Maybe should point at and can be


Question: sha256 = "3c0f73db9f8392f7048c8a244809f154d7c39f354e2167f6c477630aa517ed04"; }; <ins> propagatedBuildInputs = [ setuptools ]; </ins> patches = [ (fetchpatch { stripLen = 2;

Describe the bug fails to run because setuptools is no longer propagated implictly. If were purely a python application built with then we would just need to add to propagatedBuildInputs and be done. However, is not simply a Python application, but a wrapper around , and isn't built using. The derivation patches the script as follows: This does result in the site-packages directories from all python packages ending up in , including setuptools (e.g. ). I'm not that familiar with Python packaging but from experimenting I found that the full path to the Python egg needs to be included (e.g. ) in order for this method to work. I made an attempt at resolving the issue but being new to Python packaging in Nix, neither are likely to be ideal: We could use buildPythonPackage in place of mkDerivation, using and use Or continue to use mkDerivation and manually set for patchPythonScript: I'm happy to submit a PR but I'm not sure what the recommended solution is here. To Reproduce Steps to reproduce the behavior: Expected behavior should launch with the extension loaded: Metadata system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
It seems is normally used by adding a to , or calling with (what the wrapper registered in does). This script then just does some addition calculations to register itself (we probably don't that at all) and some python 2 specific fixups, and then calls , which starts executing some code on import. I'd suggest to package it as a regular python application first (via ), so you can successfully import it inside a . The python tooling should automatically take care of patching the python shebang properly if you make script executable.
proposed fix


Question: }; nativeBuildInputs = [ makeWrapper unzip ]; <del> buildInputs = [ ant jre8 jdk8 gtk3 gsettings-desktop-schemas ]; </del> <ins> buildInputs = [ ant jdk gtk3 gsettings-desktop-schemas ]; </ins> postPatch = '' sed -i -e 's,../SweetHome3D,${applicationSrc},g' build.xml

Wanted to install and start sweethomed.application. the build worked without problems but when i started it, it didnt started. Steps to reproduce the behavior: sweethome3d.application via configuration file to start it Starting the Application stucks at the start screen ! Add any other context about the problem here. At the moment its installed in my user context. When i try to start it as my user over the terminal i get no errors. When i start it with "sudo sweethome3d" I get the following error, and it also dont start, also start at starting screen and vanishing from the task bar: I think these happens because its not installed as user, but propably it helps to find the issue.
Starting random applications as root seems like an unwise idea.
Apologies, I misread the error, this appears to be a separate issue
Just to confirm, which GPU do you use?
I've got the same issue, and none of the solutions given in appear to work. On my side says my GPU is . EDIT: I should mention SH3D 7.02 works fine on my setup Mmh, I just tried with , and things work just fine (even though I'm on NixOS + tells me OpenGL is happy)...
Same problem here, on NIXOS unstable. Stuck on the starting blue window. Had to install it with flatpak in the mean time... Any idea?
sorry for delay i dont get informations from messages in last time from github... really annoying... I have an Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics]
Same here, also on Intel hardware.
Based on the NixGL idea, applying the following patch works to update to the latest version and fix the driver issue on Intel. But this does not seem like the best way to go about it; I can't find a single other package messing with , and it seems more like a debugging tool than something that should be in a package.
I forgot to mention, to avoid getting terrible performance (< 1 fps), I also had to set Not sure if it's needed for others. Maybe related to my using Wayland/Sway. I also have to use to get the window displayed properly, but that's a common issue for most Java apps and tiling windowing managers.
I also ran into this issue with a Nvidia card.


Question: }; nativeBuildInputs = [ makeWrapper unzip ]; <del> buildInputs = [ ant jre8 jdk8 gtk3 gsettings-desktop-schemas ]; </del> <ins> buildInputs = [ ant jdk gtk3 gsettings-desktop-schemas ]; </ins> postPatch = '' sed -i -e 's,../SweetHome3D,${applicationSrc},g' build.xml

For me, was needed (with patch). I also needed . and didn't seem needed (or give noticable changes).


Question: - heterogeneous-list-literals - hetris - heukarya <del> - hevm </del> - HExcel - hexchat - hexif

<!-- Note that these are hard requirements --<!-- 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 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: <!-- The current version can be found easily with the same process as 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: 1.7.3 desired version: 2.0.2 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.
waiting for 0.50.0 release of
I fixed echidna.
Lovely. Thanks you so much for you effort.


Question: aesop = callPackage ../applications/office/aesop { }; <ins> AusweisApp2 = libsForQt5.callPackage ../applications/misc/ausweisapp2 { }; </ins> avidemux = libsForQt5.callPackage ../applications/video/avidemux { }; avrdudess = callPackage ../applications/misc/avrdudess { };

Project description Client for authenticating to services using a German ID Metadata homepage URL: source URL: license: EUPL platforms: unix, linux, darwin, win32


Question: url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/qtbug-77037-workaround.patch?h=packages/qt5-webengine&id=fc77d6b3d5ec74e421b58f199efceb2593cbf951"; sha256 = "1gv733qfdn9746nbqqxzyjx4ijjqkkb7zb71nxax49nna5bri3am"; }) <del> ] ++ optional stdenv.isDarwin ./qtwebengine-darwin-no-platform-check.patch; </del> <ins> ] ++ optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-darwin-fix-failed-static-assertion.patch ]; </ins> qtwebkit = [ ./qtwebkit.patch ] ++ optionals stdenv.isDarwin [ ./qtwebkit-darwin-no-readline.patch

The component of the derivation fails to compile on MacOS. But in two ways, and I can't tell what causes one or the other to trigger. On command: On command: the channel compilation failure Compiles.
It has been broken for a while now for different reasons. Maintaining it for darwin is a lot of work and nobody has stepped up to do that. Also, this is a duplicate of
By the way, what is your use case for ?
We're building a desktop version of mobile application and we need for our in-app browser with Ethereum support.


Question: url = "https://git.archlinux.org/svntogit/packages.git/plain/trunk/qtbug-77037-workaround.patch?h=packages/qt5-webengine&id=fc77d6b3d5ec74e421b58f199efceb2593cbf951"; sha256 = "1gv733qfdn9746nbqqxzyjx4ijjqkkb7zb71nxax49nna5bri3am"; }) <del> ] ++ optional stdenv.isDarwin ./qtwebengine-darwin-no-platform-check.patch; </del> <ins> ] ++ optionals stdenv.isDarwin [ ./qtwebengine-darwin-no-platform-check.patch ./qtwebengine-darwin-fix-failed-static-assertion.patch ]; </ins> qtwebkit = [ ./qtwebkit.patch ] ++ optionals stdenv.isDarwin [ ./qtwebkit-darwin-no-readline.patch

Full log: Error message: That's the result I get from my macOS remote builder. When I run the build on my desktop Mac, it builds fine and uses the impure SDK from my Catalina install (10.15.1): However, the local build displays this warning repeatedly: I assume this is related to the macOS patches and hopefully gives some clue as to why it's broken.
qtbase builds fine on hydra: qtwebengine fails:
Those links point to the same thing. Anyway, strictly speaking I'm trying to build , but it's failing in .
Can you explain what do you mean? How are you using ?
It's a dependency of . edit: sorry, I see what you mean now. is a dependency of . I was confused by the message from the build saying that QT would be installed in .
Sure, depends on . Realistically, your best bet for now is to just use anki from an old version of nixpkgs. You see, doesn't have a darwin maintainer. I think, I was the last person to fix it around last January. The problem is that it's hard to keep up with all the updates. Every "minor" Qt version bump brings serious breaking changes for on darwin (like they might not even support our version of SDK anymore...). To make things worse we port all those bumps to the stable branch, so it quickly breaks there too.
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 .
Still important to me, many qt apps are broken on darwin due to this one.


Question: mask-rcnn = callPackage ../development/python-modules/mask-rcnn { }; <ins> mat2 = callPackage ../development/python-modules/mat2 { }; </ins> matchpy = callPackage ../development/python-modules/matchpy { }; mathlibtools = callPackage ../development/python-modules/mathlibtools { };

Project description Metadata proposed package name: homepage source URL: license: platforms: probably portable to all platforms which Nix supports. requires python3, exiftool, gobject introspection


Question: +            .arg(dest_path) +            .output(); +    } <ins> +    else if is_lib { +        let _ = ::std::process::Command::new("@patchelf@/bin/patchelf") +            .arg("--set-rpath") +            .arg("@libPath@") +            .arg(dest_path) +            .output(); +    } </ins> +} + #[derive(Debug)]

Describe the bug As of rust nightly 2020-06-22, Rust nightly cannot find This issue is not present in Rust nightly 2020-06-21. To Reproduce Steps to reproduce the behavior: Expected behavior rustc works Additional context This also happens with rust nightly from Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(jade): nixpkgs: Maintainer information:
We are currently using in internally to set the elf interpreter. Looks like we need to extend this to also extend the RPATH to add zlib. If someone makes a PR, I will review it! Not sure when I would get to implement that myself.
Here is where we add :
I'm working on a patch for this. This is definitely the issue, just need to find the right way to extend the RPATH. I have something replacing it with a path containing zlib, but that overwrites the existing , which breaks it. I would like to verify what is setting there but hardcoding it should provide an early fix
Extending the RPATH seems not to have worked
I'm investigating patching the files in lib This issue may have been introduced by rust-lang/rust so it's likely the new zlib dependency shows up in the LLVM libraries


Question: #   registered in /etc/shells. The nix's bash is not in there when running #   cpu-x from nixpkgs. <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "cpu-x"; version = "5.0.4"; src = fetchFromGitHub { owner = "X0rg"; repo = "CPU-X"; <del> rev = "v${version}"; sha256 = "sha256-8jJP0gxH3B6qLrhKNa4P9ZfSjxaXTeBB1+UuadflLQo="; </del> <ins> rev = "refs/tags/v${finalAttrs.version}"; hash = "sha256-8jJP0gxH3B6qLrhKNa4P9ZfSjxaXTeBB1+UuadflLQo="; </ins> }; <del> nativeBuildInputs = [ cmake pkg-config wrapGAppsHook3 nasm makeWrapper ]; </del> <ins> nativeBuildInputs = [ cmake pkg-config wrapGAppsHook3 nasm ]; </ins> buildInputs = [ <del> gtk3 ncurses libcpuid pciutils procps vulkan-headers vulkan-loader glfw opencl-headers ocl-icd libXdmcp pcre util-linux libselinux libsepol libthai libdatrie libxkbcommon libepoxy dbus at-spi2-core </del> <ins> gtk3 gtkmm3 ncurses libcpuid pciutils procps vulkan-headers vulkan-loader glfw opencl-headers ocl-icd libXdmcp pcre util-linux libselinux libsepol libthai libdatrie libxkbcommon libepoxy dbus at-spi2-core </ins> libXtst ]; <del> postInstall = '' wrapProgram $out/bin/cpu-x  --prefix PATH : ${lib.makeBinPath [ stdenv.cc ]}  </del> <ins> preFixup = '' gappsWrapperArgs+=( --prefix PATH : ${lib.makeBinPath [ stdenv.cc ]} </ins> --prefix LD_LIBRARY_PATH : ${vulkan-loader}/lib <ins> ) </ins> ''; <del> meta = with lib; { </del> <ins> passthru = { tests = { version = testers.testVersion { package = finalAttrs.finalPackage; }; }; }; meta = { </ins> description = "Free software that gathers information on CPU, motherboard and more"; mainProgram = "cpu-x"; homepage = "https://thetumultuousunicornofdarkness.github.io/CPU-X"; <del> license = licenses.gpl3Plus; </del> <ins> license = lib.licenses.gpl3Plus; </ins> platforms = [ "x86_64-linux" ]; <del> maintainers = with maintainers; [ viraptor ]; </del> <ins> maintainers = with lib.maintainers; [ viraptor ]; </ins> }; <del> } </del> <ins> }) </ins>

When trying to start the App from the launcher, nothing happens. In the terminal starts the text based version, but typing throws the following error =Source: Also check: And this is my system: !


Question: config = mkMerge [ (mkIf cfgC.enable { <del> systemd.services."synergy-client" = { after = [ "network.target" ]; </del> <ins> systemd.user.services."synergy-client" = { after = [ "network.target" "graphical-session.target" ]; </ins> description = "Synergy client"; <del> wantedBy = optional cfgC.autoStart "multi-user.target"; </del> <ins> wantedBy = optional cfgC.autoStart "graphical-session.target"; </ins> path = [ pkgs.synergy ]; serviceConfig.ExecStart = ''${pkgs.synergy}/bin/synergyc -f ${optionalString (cfgC.screenName != "") "-n ${cfgC.screenName}"} ${cfgC.serverAddress}''; serviceConfig.Restart = "on-failure"; }; }) (mkIf cfgS.enable { <del> systemd.services."synergy-server" = { after = [ "network.target" ]; </del> <ins> systemd.user.services."synergy-server" = { after = [ "network.target" "graphical-session.target" ]; </ins> description = "Synergy server"; <del> wantedBy = optional cfgS.autoStart "multi-user.target"; </del> <ins> wantedBy = optional cfgS.autoStart "graphical-session.target"; </ins> path = [ pkgs.synergy ]; serviceConfig.ExecStart = ''${pkgs.synergy}/bin/synergys -c ${cfgS.configFile} -f ${optionalString (cfgS.address != "") "-a ${cfgS.address}"} ${optionalString (cfgS.screenName != "") "-n ${cfgS.screenName}" }''; serviceConfig.Restart = "on-failure";

Synergy crashes without an X Display available, but the autostart option attempts to start synergy regardless of whether login is graphical or TTY. It would probably make more sense to spawn this after
(triage) status?
In case this is still relevant - would it make sense for those to run as user services instead to take advantage of recent changes merged in
I think this is probably still relevant, and I think your suggestion is probably a good one, . With this config: out of the box, I get the following: But if I kill the service and start the synergyc command manually as my unprivileged desktop user, it works just fine:


Question: owner = "named-data"; repo = "ndn-cxx"; rev = "${pname}-${version}"; <del> sha256 = "1lcaqc79n3d9sip7knddblba17sz18b0w7nlxmj3fz3lb3z9qd51"; </del> <ins> sha256 = "sha256-oTSc/lh0fDdk7dQeDhYKX5+gFl2t2Xlu1KkNmw7DitE="; </ins> }; nativeBuildInputs = [ doxygen pkg-config python3 python3Packages.sphinx wafHook ]; <del> buildInputs = [ boost openssl sqlite ]; </del> <ins> buildInputs = [ boost175 openssl sqlite ]; </ins> wafConfigureFlags = [ "--with-openssl=${openssl.dev}" <del> "--boost-includes=${boost.dev}/include" "--boost-libs=${boost.out}/lib" </del> <ins> "--boost-includes=${boost175.dev}/include" "--boost-libs=${boost175.out}/lib" # "--with-tests" # disabled since upstream tests fail (Net/TestFaceUri/ParseDev Bug #3896) </ins> ]; <ins> doCheck = false; # disabled since upstream tests fail (Net/TestFaceUri/ParseDev Bug #3896) checkPhase = '' runHook preCheck LD_PRELOAD=build/ndn-cxx.so build/unit-tests runHook postCheck ''; </ins> meta = with lib; { homepage = "https://named-data.net/"; description = "A Named Data Neworking (NDN) or Content Centric Networking (CCN) abstraction";

The default boost version has been bumped from 1.69 (or 1.75) to 1.77. This is a notice for maintainers that the following packages are now failing to build: - - - - - - - - - - [x] cryfs A typical fix would involve pinning the package to a specific version (e.g. see )
My fix in is not the same as . Is there a very good reason to prefer one over the other ?
Well, I like trying to keep it away from the huge top-level file. (which is e.g. harder to use in git)
Re. pivx, I think we should mark it broken. Our current version is very old (and therefore useless), and the new version includes a rust build. I don't have the capacity to fix this ATM.
In my case, what broke it was the update from boost175 to boost177. Fix is in .
It's in the branch now, so please target any further fixes there as well (unless they're a mass rebuild, etc.)
colobot fixed with
FYI, ledger has some broken behavior with the new boost version, although it curiously doesn't cause a test failure: ledger/ledger.
Our expression does not attempt to run tests.
Ah, that would be why, thanks. Nevertheless, the binary exhibits the same problem described in that issue in interactive use.


Question: </varlistentry> <varlistentry> <term> <del> GStreamer </del> <ins> GNOME platform </ins> </term> <listitem> <para> <del> Adds the GStreamer plugins subdirectory of each build input to the <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> or <envar>GST_PLUGIN_SYSTEM_PATH</envar> environment variable. </del> <ins> Hooks related to GNOME platform and related libraries like GLib, GTK and GStreamer are described in <xref linkend="sec-language-gnome" />. </ins> </para> </listitem> </varlistentry>

I just found out about wrapGAppsHook by examining a gnome package, but there really should be documentation about this in the Nixpkgs User Guide (a section about Gnome would be nice, which would show the right way to package GTK3 / GTK2 glib based apps). Also, perhaps there are other things I missed that one should know when packaging Gnome Applications or GTK3/2 apps? /cc Gnome maintainers
I'd like to know as well. Currently receiving this error: On one of the packages I'm trying to put into nixpkgs. Apparently sometimes you need for buildInputs. So apparently all you need to do to use this is:
The error occurs when you do not have any directory containing in variable. One of the things does is (which usually contains the aforementioned file) of dependencies to . (Actually this happens in cooperation with via variable.) Icon themes work in the same vein, only is used and it is populated by which is propagated to (). (XDG fallback theme) should be probably to any GTK application that uses icons (I think that is every GTK applicaton nowadays due to CSD) but some applications require Adwaita because they use icons not in hicolor. Not sure if this functions correctly though, at least it should not according to my mental model of how icon theme selection works; I will need to read the relevant XDG spec before I can finish the documentation.
Just thought I'd leave this comment here for future reference: if you get an error like for python gtk applications, try adding to propogatedBuildInputs!
It should go to , though. But be wary of


Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=9.8 (nixos-20.03) Scanned versions: nixos-20.03: . May contain false positives. Cc Cc
See also: , ,


Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=9.8 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc
See also:


Question: stdenv.mkDerivation rec { pname = "sqlite"; <del> version = "3.32.2"; </del> <ins> version = "3.32.3"; </ins> # NB! Make sure to update analyzer.nix src (in the same directory). src = fetchurl { url = "https://sqlite.org/2020/sqlite-autoconf-${archiveVersion version}.tar.gz"; <del> sha256 = "1130bcd70s2vlsq0d638pb5qrw9kwqvjswnp2dfypghx9hjz3gid"; </del> <ins> sha256 = "0rlbaq177gcgk5dswd3akbhv2nvvzljrbhgy18hklbhw7h90f5d3"; </ins> }; outputs = [ "bin" "dev" "out" ];

, CVSSv3=7.5 (nixos-20.03, nixos-unstable) Scanned versions: nixos-20.03: ; nixos-unstable: . May contain false positives. Cc Cc