jiebi/CodeConvo huggingface dataset:
Change:
# Clang doesn't support "-export-dynamic" ++ optional stdenv.cc.isClang "-DPYTHON_LINKFLAGS=" ++ optional jackaudioSupport "-DWITH_JACK=ON" <del> ++ optional cudaSupport "-DWITH_CYCLES_CUDA_BINARIES=ON"; </del> <ins> ++ optional cudaSupport [ "-DWITH_CYCLES_CUDA_BINARIES=ON" "-DWITH_CYCLES_DEVICE_OPTIX=ON" "-DOPTIX_ROOT_DIR=${optix}" ]; </ins> NIX_CFLAGS_COMPILE = "-I${ilmbase.dev}/include/OpenEXR -I${python}/include/${python.libPrefix}";

Discussion:
Feature request As the title says, enable OptiX in Blender. I considered adding OptiX as a package request, but it seems like Nvidia wants to be the only one to distribute that package. How Arch linux has implemented it I looked at the PKGBUILD of Blender for arch, and they package OptiX with the blender package. How the Blender documentation suggests implementing it page describes what needs to be done to activate OptiX in the build process. To summarize: Install OptiX SDK 7.0, and add the following build flags I could try implementing this myself, but I don't know if I'll succeed, since I'm very new to NixOS. Would submitting a pull request where I've done my what I can be any helpful? Notify maintainers
I'm currently using this overlay, which seems to work: I won't have much time during the next two days, but after that if no one else has done it already I'm happy to make a PR. In the meantime, using the above overlay should work if you need OptiX support right now.
I have created a pull request, to the best of my abilities:
Change:
buildInputs = [ ncurses pcre ]; <del> configureFlags = [ "--enable-maildir-support" "--enable-multibyte" "--enable-zprofile=$out/etc/zprofile" "--with-tcsetpgrp" "--enable-pcre" ]; </del> <ins> preConfigure = '' configureFlags="--enable-maildir-support --enable-multibyte --enable-zprofile=$out/etc/zprofile --with-tcsetpgrp --enable-pcre" ''; </ins> # the zsh/zpty module is not available on hydra # so skip groups Y Z

Discussion:
To make sure that we are on the same page: Kernel: (run ) Linux lapole 3.18.25 -NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x8664 GNU/Linux System: (NixOS: , Ubuntu/Fedora: , ...) 15.09.952. (Dingo) Nix version: (run ) nix-env (Nix) 1.10 Nixpkgs version: (run ) 16.03pre75806. I installed zsh-5.2 from nixpkgs channel to get away from a 5.0.8 bug. After I changed my login-shell to 5.2, ssh logins were no longer functional. Ie. PATH wasn't fully initialized. Reverting to 5.0.8 fixed the problem. I'm not sure why there's a difference between regular login shells and ssh though. Running yields: For 5.0.8 I get the expected /nix/store/... path instead of the strange $out path. The line with $out seems wrong.. Checking the commit log I find Dropping into nix-shell for zsh-5.2, setting and manually running I get: So it seems to me that variables in is not expanded leading to zprofile not being run. It could be something else of course (not everything seems to add up without more investigating), but the $out thing seems wrong either way.
cc
This is fixed by the merge of . Cherry-picked to .
Change:
buildPythonPackage { pname = "std2"; <del> version = "unstable-2023-10-07"; </del> <ins> version = "0-unstable-2024-09-02"; </ins> pyproject = true; src = fetchFromGitHub { owner = "ms-jpq"; repo = "std2"; <del> rev = "6332e559ee51c3a7c956804afdd7e1cc6ad47965"; hash = "sha256-huN7P/Ws6anrFXDG7L5xxMenS25BHquV9cMi1s7WFJ4="; </del> <ins> rev = "205d1f52e9b5438ef2b732c77e1144847cafa8d0"; hash = "sha256-WdUefadEk92cGnDI+KbQBpjg+d7KgI6bjlQlyhRRRFA="; </ins> }; nativeBuildInputs = [ setuptools ]; <del> meta = with lib; { </del> <ins> meta = { </ins> homepage = "https://github.com/ms-jpq/std2"; description = "Dependency to chadtree and coq_nvim plugins"; <del> license = licenses.gpl3Plus; maintainers = with maintainers; [ GaetanLepage ]; </del> <ins> license = lib.licenses.gpl3Plus; maintainers = with lib.maintainers; [ GaetanLepage ]; </ins> }; }

Discussion:
Package name: python312Packages.std2 Latest released version: 2024-09-01 <!-- Search your package here: --- Current version on the unstable channel: 2023-10-07 Current version on the stable/release channel: 2023-10-07 <!-- 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]:
Change:
systemd.packages = packages; environment.variables = { <del> GTK_USE_PORTAL = optional cfg.gtkUsePortal "1"; </del> <ins> GTK_USE_PORTAL = mkIf cfg.gtkUsePortal "1"; </ins> XDG_DESKTOP_PORTAL_PATH = map (p: "${p}/share/xdg-desktop-portal/portals") cfg.extraPortals; }; };

Discussion:
Firefox is run with . Console output:
Disabling it asking this should quiet the issue until it's resolved. I can confirm that the associations are at least correct.
So I guess they should be doing the same as for snap? In this case, I noticed that doing will still return an empty list so it ends up doing By using we can prevent that.
I don't think that's quite it. There seems to be a fundamental confusion; the that: But of course you don't need to be running in a sandbox to use the functionality they provide. Yet firefox is using the presence of to determine if the application is running in a flatpak container. This isn't going to work if people use portals for other reasons. What they should be doing, I think, is the same as for snap, if the program is running . They probably also need a more fine-grained way to instruct firefox to use a portal for the file chooser without affecting other functionality: (Here's why it doesn't actually check the value of GTKUSEPORTAL: )
That doesn't fix the issue in firefox, in the report this behavior was triggered even if the variable was set in the environment. And in general that probably shouldn't be happening so I fixed that.
Not sure what you mean, but I wasn't disagreeing with the thing, just bouncing ideas about how Firefox could improve their behaviour. I'll take the suggestions upstream if I find the time.
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 .
I still have this issue. Is there a workaround?
I am experiencing this issue atm. Every link I click tries to open in firefox but ends up doing nothing and firefox prompts me to set it as the default browser on every run.
I marked this as stale due to inactivity.

&rarr;
Also have this issue after setting for firefox-wayland
Stupid workaround for lazy home-manager users: add to .
This is an upstream bug that was linked to earlier in the thread, right? Do we need to track that bug downstream?
I haven't experienced this anymore in a long time.
I marked this as stale due to inactivity. &rarr;
Change:
, enableSdl2 ? false, SDL2, SDL2_image, SDL2_sound, SDL2_mixer, SDL2_ttf }: <del> stdenv.mkDerivation rec { </del> <ins> stdenv.mkDerivation (finalAttrs: { </ins> pname = "angband"; version = "4.2.5"; src = fetchFromGitHub { owner = "angband"; repo = "angband"; <del> rev = version; sha256 = "sha256-XH2FUTJJaH5TqV2UD1CKKAXE4CRAb6zfg1UQ79a15k0="; </del> <ins> rev = finalAttrs.version; hash = "sha256-XH2FUTJJaH5TqV2UD1CKKAXE4CRAb6zfg1UQ79a15k0="; </ins> }; nativeBuildInputs = [ autoreconfHook ]; buildInputs = [ ncurses5 ] ++ lib.optionals enableSdl2 [

Discussion:
Steps to reproduce the behavior: angband macOS Sonoma 14.3 Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
could you include entire build log?
It works now. THANKS DEVS!
Change:
<ins> { stdenv, lib, fetchFromGitHub, libsForQt5, qt5, makeDesktopItem, nix-update-script, copyDesktopItems, }: stdenv.mkDerivation (finalAttrs: { pname = "qtalarm"; version = "2.5.1"; src = fetchFromGitHub { owner = "CountMurphy"; repo = "QTalarm"; rev = "refs/tags/${finalAttrs.version}"; hash = "sha256-87w5YFQ9olLnCfPF04jOnIMn1NtE2M2n5WZX4e69UGU="; }; buildInputs = [ libsForQt5.qtbase libsForQt5.qtmultimedia ]; installPhase = '' runHook preInstall '' + ( if stdenv.isDarwin then '' mkdir -p $out/Applications mv qtalarm.app $out/Applications '' else '' install -Dm755 qtalarm -t $out/bin install -Dm644 Icons/1349069370_Alarm_Clock.png $out/share/icons/hicolor/48x48/apps/qtalarm.png install -Dm644 Icons/1349069370_Alarm_Clock24.png $out/share/icons/hicolor/24x24/apps/qtalarm.png install -Dm644 Icons/1349069370_Alarm_Clock16.png $out/share/icons/hicolor/16x16/apps/qtalarm.png '' ) + '' runHook postInstall ''; nativeBuildInputs = [ qt5.wrapQtAppsHook qt5.qmake copyDesktopItems ]; passthru.updateScript = nix-update-script { }; desktopItems = [ (makeDesktopItem { name = "QTalarm"; exec = "qtalarm"; icon = "qtalarm"; desktopName = "QTalarm"; genericName = "Nifty alarm clock"; categories = [ "Application" "Utility" ]; terminal = false; }) ]; meta = { description = "Nifty alarm clock written in QT"; changelog = "https://github.com/CountMurphy/QTalarm/releases/tag/${finalAttrs.version}"; homepage = "https://github.com/CountMurphy/QTalarm"; license = lib.licenses.gpl3Only; mainProgram = "qtalarm"; maintainers = with lib.maintainers; [ bot-wxt1221 ]; platforms = lib.platforms.unix; }; }) </ins>

Discussion:
QTalarm is a lightweight alarm package with few dependencies other than qt, I use it to have a nice calendar popup when clicking on my clock in waybar <!-- Describe the project a little: --Metadata homepage URL: source URL: license: GPL platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<del> { stdenv, lib, fetchFromGitHub, pkgconfig, cmake, qtbase, qttools </del> <ins> { mkDerivation, lib, fetchFromGitHub, pkgconfig, cmake, qtbase, qttools </ins> , seafile-shared, ccnet, jansson, libsearpc , withShibboleth ? true, qtwebengine }: <del> stdenv.mkDerivation rec { </del> <ins> mkDerivation rec { </ins> pname = "seafile-client"; version = "7.0.5";

Discussion:
Describe the bug The binary fails to launch in . Output: To Reproduce Steps to reproduce the behavior: to vis CLI Expected behavior The Seafile Applet starts without issues. Additional context This could be related to a missing , however looks like it does include an alternative way of the hook. Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(wucke13): nixpkgs: Maintainer information:
Can you try to see if adding helps?
Fixing this now.
That's a fast response, thank you both! Just wondering: Why didn't this occur earlier?
It was large issue that a lot of qt apps in nixpkgs weren't packaged correctly Hopefully people will read the qt section of the manual now, since it's always been to do
Oh, I'm well aware of the Qt Apps problem in general. What I'm wondering is why I did not run into this issue before 20.03. I'm using seafile since 17.03, and I'm not using a Qt DE that circumvents the problem, so I'm wondering why this problem ocured first in 20.03.
Me trying to run it from nixos-unstable results in That is indeed strange.
I figured out the timeline and why you just now experienced this issue
Change:
substituteInPlace Makefile --replace "-Werror" "-Werror -Wno-stringop-truncation" ''; <del> postInstall = '' cp src/proxychains.conf $out/etc ''; </del> meta = with lib; { description = "Proxifier for SOCKS proxies"; homepage = "http://proxychains.sourceforge.net";

Discussion:
Instead of reading config file generated with , proxychains reads config from the program's store path. and check its output Here proxychains uses (from the default config) as proxy. proxychains reads config from , and uses as proxy. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Please run and paste the result. Maintainer information:
Thanks for the report! I remember that sample config was to in as part of the . Not sure why it suddenly causes problems (although according to its it looks in its root before ). Can you try with that one commit reverted and possibly submit a PR if it helps?
Thank you, it works! I'll open a PR shortly.
same proxy using socks5://127.0.0.1:1080 which is my option the config seems okay the source of so you see the hash of proxychians default config differs from that of nix-generated config, and proxychains use the default config which makes the programs.proxychians.proxies option useless
Related:
I found looks similar with . However, many options while proxychains-ng doesn't have them. Should we provide same options for proxychains-ng?
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
sha256 = "0s8bljn4ga2hj480j0jwkc0npp8szbmirmcsys791gk32iq4dasn"; }; <del> pythonPath = [ dockbarx ]; </del> <ins> pythonPath = [ dockbarx python3Packages.pygobject3 ]; </ins> <del> nativeBuildInputs = [ pkg-config wafHook ]; buildInputs = [ python3 vala_0_48 gtk2 pythonPackages.wrapPython ] ++ (with xfce; [ libxfce4util xfce4-panel xfconf xfce4-dev-tools ]) ++ pythonPath; </del> <ins> nativeBuildInputs = [ gobject-introspection pkg-config python3Packages.wrapPython vala_0_48 wafHook wrapGAppsHook ]; buildInputs = [ keybinder3 python3Packages.python xfce.xfce4-panel xfce.xfconf ] ++ pythonPath; </ins> postPatch = '' substituteInPlace wscript           --replace /usr/share/            "''${PREFIX}/share/"

Discussion:
Describe the bug xfce-dockbarx plugin fails to work due to missing library 'gi'; it shows nothing insdide the xfce panel. To Reproduce Steps to reproduce the behavior: xfce installed xfce.xfce4-dockbarx-plugin and dockbarx installed add dockbarx to the panel of XFCE the xfce panel 4-panel to show the error Expected behavior dockbarx shows up on the menu, with no errors in the terminal, with a taskbar in the panel Additional context Terminal output: Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(james): nixpkgs: Maintainer information:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
tests.version = testers.testVersion { package = dolphin-emu; command = "dolphin-emu-nogui --version"; <ins> version = if stdenv.hostPlatform.isDarwin then "Dolphin 5.0" else version; </ins> }; updateScript = writeShellScript "dolphin-update-script" ''

Discussion:
Steps to reproduce the behavior: dolphin-emu on nixpkgs-unstable Add any other context about the problem here. Please run and paste the result.
Change:
stdenv.mkDerivation rec { pname = "proot"; <del> version = "5.1.0.20190305"; </del> <ins> version = "20190510"; </ins> src = fetchFromGitHub { repo = "proot"; owner = "proot-me"; <del> rev = "ff61c86cb26f71c06af22574d9d4cc3a77292781"; sha256 = "0qink34bjv0lshf3c8997w39r8yxgbhxpjbxw47l5xkvimlpc0dl"; </del> <ins> rev = "803e54d8a1b3d513108d3fc413ba6f7c80220b74"; sha256 = "0gwzqm5wpscj3fchlv3qggf3zzn0v00s4crb5ciwljan1zrqadhy"; </ins> }; postPatch = ''

Discussion:
So today I tried to build on unstable as described in the . This fails on the dependency . Thanks for your information in that guide! I tried to build according to the guide on and (with slight modifications for compatibility) on they both fail in at this point. Do you have any insights as to how you managed to get it to build? e.g. a nixpkgs commit?
Fix in
Change:
pysolcast = callPackage ../development/python-modules/pysolcast { }; <ins> pystac = callPackage ../development/python-modules/pystac { }; </ins> pysubs2 = callPackage ../development/python-modules/pysubs2 { }; pysuez = callPackage ../development/python-modules/pysuez { };

Discussion:
Project description User friendly Rasterio plugin to read raster datasets. Metadata homepage URL: source URL: license: bsd platforms: unix Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Already packaged by in . Should be easy to add to nixpkgs.
Requires morecantile and pystac, that shoud be to nixpkgs as well.
Change:
<del> { stdenv, fetchurl, libpcap, openssl, zlib, wirelesstools, libnl, pkgconfig }: </del> <ins> { stdenv, fetchurl, libpcap, openssl, zlib, wirelesstools , iw, ethtool, pciutils, libnl, pkgconfig, makeWrapper }: </ins> stdenv.mkDerivation rec { name = "aircrack-ng-1.2-rc4";

Discussion:
I installed from and it complains that is not avaiable while it is. Steps to reproduce: either from or (replace wlp3s0 with your wireless interface name, you can see a list by running ) that it complains that it can't do that because is missing, then run to prove that it's not
(triage) still a problem?
I stopped using NixOS half year ago, but reinstalled it this morning (what a coincidence). I'll check as soon as I can!
aircrack now works, but it still complains about missing required software for the airmon functionality: ethtool, lsusb (found in usbutils) and iw. Should these be runtime dependencies of aircrack? Some of its functionality won't work without these, but they can be installed manually and it will work. This is on current unstable.
If it needs those at runtime, you should probably use and call (in in the .
Change:
}; goldendict = libsForQt5.callPackage ../applications/misc/goldendict { }; <ins> goldendict-ng = qt6Packages.callPackage ../applications/misc/goldendict-ng { }; </ins> gomuks = callPackage ../applications/networking/instant-messengers/gomuks { };

Discussion:
Project description A fork of Golden Dictionary which fixes many old bugs, provides improvement, and is being actively developed. It might be better to switch to altogether instead of continuing to maintain . Metadata homepage URL: source URL: license: gplv3 platforms: linux
doesn't seem too inactive now: they even had a new release last month (based on Qt WebKit, though).
I think it might be a good idea to have both versions as provides extra features and bug fixes if that's possible.
Change:
installPhase = '' runHook preInstall <del> mkdir -p $out/bin $out/share/${pname} $out/share/applications cp -a ${appimageContents}/{locales,resources} $out/share/${pname} </del> <ins> mkdir -p $out/bin $out/share/${pname} $out/share/applications $out/share/${pname}/resources/app/icons cp -a ${appimageContents}/resources/app/icons/logseq.png $out/share/${pname}/resources/app/icons/logseq.png </ins> cp -a ${appimageContents}/Logseq.desktop $out/share/applications/${pname}.desktop <del> # remove the `git` in `dugite` because we want the `git` in `nixpkgs` chmod +w -R $out/share/${pname}/resources/app/node_modules/dugite/git chmod +w $out/share/${pname}/resources/app/node_modules/dugite rm -rf $out/share/${pname}/resources/app/node_modules/dugite/git chmod -w $out/share/${pname}/resources/app/node_modules/dugite </del> <ins> # set the env "LOCAL_GIT_DIRECTORY" for dugite so that we can use the git in nixpkgs makeWrapper ${appimage-run}/bin/appimage-run $out/bin/logseq  --set "LOCAL_GIT_DIRECTORY" ${git}  --add-flags ${src} # Make the desktop entry run the app using appimage-run </ins> substituteInPlace $out/share/applications/${pname}.desktop  <del> --replace Exec=Logseq Exec=${pname}  </del> <ins> --replace Exec=Logseq "Exec=$out/bin/logseq"  </ins> --replace Icon=Logseq Icon=$out/share/${pname}/resources/app/icons/logseq.png runHook postInstall ''; <del> postFixup = '' # set the env "LOCAL_GIT_DIRECTORY" for dugite so that we can use the git in nixpkgs makeWrapper ${electron}/bin/electron $out/bin/${pname}  --set "LOCAL_GIT_DIRECTORY" ${git}  --add-flags $out/share/${pname}/resources/app ''; </del> passthru.updateScript = ./update.sh; meta = with lib; {

Discussion:
When exporting the graph, logseq throws a permission exception. Steps to reproduce the behavior: a new graph a few pages them public ()) the graph The graph should successfully export and opening it should show a read-only view of the graph. The logseq documentation itself is an example thereof. If applicable, add screenshots to help explain your problem. Bug was first reported in the original repo When running the AppImage with it's fine because it's extracted into , but when the app is in then it won't work because of the read-only status. I tested the flatpak version because I suspected the same problem would occur, but the directories are mounted read-write in a read-only volume. So, 2 options exist as I see it: fix it upstream, but I don't know Clojure nor Electron start the AppImage with instead of extracting it Please run and paste the result.
Change:
, doCheck ? config.doCheckByDefault or false , coreutils, dbus, libxml2, tzdata , desktop-file-utils, shared-mime-info <del> , darwin </del> <ins> , darwin, fetchpatch </ins> }: with stdenv.lib;

Discussion:
Describe the bug is broken on Darwin. git bisect shows (part of ) as the first failing commit To Reproduce Try to build on Darwin at <details<summarynix-build -A gobject-introspection </summary</detailsExpected behavior Able to build on Darwin Additional context <!-- There is a 10 years old bug report with the same error message --Metadata Maintainer information: cc:
Looks like this upstream issue: . It's fixed on master so we should probably pick the patches.
Our jobset needs to be building on the darwin platform if we don't want things breaking like this.
Change:
allPackages = withPackages (filter self.lib.isUnbrokenAgdaPackage (attrValues self)); }; }; <del> inherit (Agda) meta; </del> <ins> # Agda is a split package with multiple outputs; do not inherit them here. meta = removeAttrs Agda.meta [ "outputsToInstall" ]; </ins> } '' mkdir -p $out/bin <del> makeWrapper ${Agda}/bin/agda $out/bin/agda  </del> <ins> makeWrapper ${Agda.bin}/bin/agda $out/bin/agda  </ins> --add-flags "--with-compiler=${ghc}/bin/ghc"  --add-flags "--library-file=${library-file}" <del> ln -s ${Agda}/bin/agda-mode $out/bin/agda-mode </del> <ins> ln -s ${Agda.bin}/bin/agda-mode $out/bin/agda-mode </ins> ''; withPackages = arg: if isAttrs arg then withPackages' arg else withPackages' { pkgs = arg; };

Discussion:
With the standard library, cubical and categories, agdaWithPackages has a closure size of about 4.9 GiB (): Among the larger culprits are 600 MiB of libHSAgda-[...].a and GHC itself. Personally I'm using where I zero out the dependence on GHC and just fetch the Agda binary. I've been using this for years and never encountered any problems. Should we incorporate something like this in nixpkgs?
I currently have a number of parallel installations of Agda on my machines, and I'd like to see a reduction of closure size. I think there are two separate space hogs: Haskell library. The mentions two helpers to reduce closure size: (removes references to libraries and docs) and (installs binaries in a separate output). I tried setting , but it breaks .<supSee below</supattribute passed to : I don't use Agda's GHC backend, so I provide a "fake GHC" to reduce closure size: Maybe could be changed so that disables compilation via GCH. E.g. we could pass and to the wrapped binary. I applied to the Haskell package . Running results in the following output: Result of run on x86_64-linux <details<summary2 packages marked as broken and skipped:</summary<ul<licedille</li<liemacsPackages.cedille</li</ul</details<details<summary1 package failed to build:</summary<ul<liemacsPackages.agda2-mode</li</ul</details<details<summaryBuild log of <codeemacsPackages.agda2-mode</code</summary</details