jiebi/CodeConvo huggingface dataset:
Change:
buildInputs = cryptoLibsMap.${cryptoStr} ++ [ boost ceph-python-env libxml2 optYasm optLibatomic_ops optLibs3 malloc zlib openldap lttng-ust babeltrace gperf gtest cunit <del> snappy rocksdb lz4 oathToolkit leveldb libnl libcap_ng rdkafka </del> <ins> snappy lz4 oathToolkit leveldb libnl libcap_ng rdkafka </ins> ] ++ lib.optionals stdenv.isLinux [ linuxHeaders util-linux libuuid udev keyutils optLibaio optLibxfs optZfs # ceph 14

Discussion:
Describe the bug Using ceph-volume to create a new bluestore-backed OSD doesn't work. To Reproduce Steps to reproduce the behavior: -volume lvm create --data /dev/sda --bluestore --no-systemd Expected behavior A clear and concise description of what you expected to happen. A new Bluestore OSD (on LVM) is successfully provisioned. Switching RocksDB to the Ceph-bundled copy rather than the OS version makes it work. I note that the Ceph NixOS test uses filestore instead. Screenshots If applicable, add screenshots to help explain your problem. Additional context Add any other context about the problem here. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: nixpkgs: Maintainer information:
Change:
pcre systemd tbb <del> wxGTK31-gtk3 </del> <ins> wxGTK31-gtk3-override' </ins> xorg.libX11 ] ++ checkInputs;

Discussion:
prusa-slicer crashes, maybe related to our wxWidgets version. See for now. cc
Maybe caused by Maybe backport that change, or use the prusa-slicer wxWidget fork.
I can reproduce it with nixpkgs rev Using the wxWidgets fork from prusa3d fixes the issue. Will try to write a PR soon.
Change:
# nix-serve = 199; # unused, removed 2020-12-12 #tvheadend = 200; # dynamically allocated as of 2021-09-18 uwsgi = 201; <del> gitit = 202; </del> <ins> # gitit = 202; # unused, module was removed 2023-04-03 </ins> riemanntools = 203; subsonic = 204; # riak = 205; # unused, remove 2022-07-22

Discussion:
This is essentially a repost of : We have a NixOS module for gitit in nixpkgs which due to its impact on evaluation performance. It continued to be shipped, so that one could include it manually, but it has bitrotted since then. One thing I noticed is that it makes an incorrect assumption where gitit's data files would be located, but there may be more issues. It would be great if we could either find someone willing to fix the module up or drop it altogether.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
if someone wants to fix it then the options should be converted to freeform and
At this time, I don't see anymore, neither in 22.11, neither in unstable. I am closing.
I still see on master. It was however excluded from evaluation in Edit: wrong commit, that just a space. . So it hasn't been evaluated since 2015… There's also some comments on that commit.
Oh thank you for correcting me. I used I am in favor of dropping it, I guess. It's not easy to discover and someone else can revive it at some point.
see IMO if nobody has stepped up in the years since, it hasn't been a priority to anyone. We can wait a few days for comments on . Then again, if someone still needs it, they can always revert/take it from the history.
Change:
, fetchFromGitHub , cmake , ninja <del> , jdk8 </del> , jdk17 , zlib <del> , file , wrapQtAppsHook , xorg , libpulseaudio </del> , qtbase <del> , qtsvg , qtwayland , libGL </del> , quazip <del> , glfw , openal </del> , extra-cmake-modules , tomlplusplus , ghc_filesystem <del> , msaClientID ? "" , jdks ? [ jdk17 jdk8 ] , gamemodeSupport ? true </del> , gamemode <ins> , msaClientID ? null , gamemodeSupport ? true </ins> }: let libnbtplusplus = fetchFromGitHub { owner = "PrismLauncher";

Discussion:
It's common to use custom builds of GLFW with Minecraft, for things like improved Wayland support. At the moment, Prism Launcher is built and wrapped in a . This means that overriding libraries such as GLFW, that aren't actually used in the build process but rather used by prebuilt copies of Minecraft at runtime, result in a binary cache miss - triggering local a rebuild of the entire launcher. I propose that the wrapping pattern is implemented here, building the launch wrapper in a new derivation. This way, runtime dependencies can be changed without changing the hash of the launcher binary derivation.
This sounds like a good idea to me, let's do this
Change:
fixDarwinDylibNames = makeSetupHook { } ../build-support/setup-hooks/fix-darwin-dylib-names.sh; <ins> fixDarwinFrameworks = makeSetupHook { } ../build-support/setup-hooks/fix-darwin-frameworks.sh; </ins> keepBuildTree = makeSetupHook { } ../build-support/setup-hooks/keep-build-tree.sh; enableGCOVInstrumentation = makeSetupHook { } ../build-support/setup-hooks/enable-coverage-instrumentation.sh;

Discussion:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.

I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.
Change:
<del> { stdenv, fetchFromGitHub, fontforge, pythonPackages, python }: </del> <ins> { stdenv, fetchFromGitHub, fontforge, python3Packages, python3 }: </ins> stdenv.mkDerivation rec { pname = "liberation-sans-narrow";

Discussion:
Describe the bug Trying to rebuild from git master and it complains about fonttools and python version mismatch. To Reproduce Metadata Please run and paste the result. root nix run -c nix-info -m system: host os: multi-user?: sandbox: version: nixpkgs: channels(root): Maintainer information:
Looks like an issue with trying to build it with Python 2.7.x. The code isn't entirely compatible with Python 3.x nevertheless.
The issue seems to be with nototools which we currently have disabled for python3. The last nototools release is apparently fully compatible with python3. I'm working on a fix for this, however, the build now has a strange relationship with noto-fonts that I haven't quite figured out yet.
In the latest release nototools seems to still fail, or at least does on mine. The only relationship I found is that nototools is a dependency on noto-fonts.
you mean when running , or something similar? That's expected since nototools has been disabled for python3 (python3 support has only recently been upstream). I believe the relationship is actually that nototools is a dep of noto-fonts-emoji. The current nototools seems to require noto-fonts as a dep. I've gotten most of the way to a fix I think (changed nototools version and enabled py3 and what we fetch with the fetchZip in noto-fonts). However, the way that nototools expects noto-fonts is pretty strange (as an example look at the top level makefile where it looks for the noto-fonts repo in nototools' parent directory). I'm having a bit of trouble getting noto-fonts in the form nototools expects. I'm trying not to just copy the entire noto-fonts source into nototools source which seems like it should be unnecessary. Once nototools is fixed for python3 the rest should be easy bc we can just change noto-fonts etc to use python3. If you have any thoughts on how to fix nototools I'd love to hear them, or if you think I'm missing something here pls do let me know.
should be a dependency of the derivation. I'm not sure where you're seeing the fact that needs as a dependency.

The farthest I've gotten is removing all the errors from the configuration but the build still fails with .
You mean that it should be a dependency of or it is currently? In regard to "is currently" I don't see it as currently being a dependency. The only place appears in noto- is in the following lines as part of derivation. If you mean it should be, then how you get to build on its own? If you change the nototools version to 0.2.0 which adds python3 support I get errors about missing font directories (these directories come from noto-fonts). What am I missing here?
Proposed fix Still building though...
, and have the same error.
Change:
] ++ lib.optionals stdenv.isDarwin [ "-DLIBDIR=/does-not-exist" <del> "-DWITH_CYCLES_OSL=OFF" # causes segfault on aarch64-darwin </del> "-DSSE2NEON_INCLUDE_DIR=${sse2neon}/lib" "-DWITH_USD=OFF" # currently fails on darwin ] ++ lib.optional stdenv.cc.isClang "-DPYTHON_LINKFLAGS=" # Clang doesn't support "-export-dynamic" <del> ++ lib.optional jackaudioSupport "-DWITH_JACK=ON" </del> ++ lib.optionals cudaSupport [ "-DOPTIX_ROOT_DIR=${optix}" "-DWITH_CYCLES_CUDA_BINARIES=ON" <del> "-DWITH_CYCLES_DEVICE_OPTIX=ON" </del> ]; preConfigure = ''

Discussion:
makes blender crash on start on my machine with Nvidia GPU running Hyprland I think it's a Nvidia issue because I can't repro on Intel iGPU machine blender from current built channel (which is also my system's channel; note that I rebooted after , so probably not a gl driver mismatch issue): blender built from slightly older commit works (which is also blender 4.2.1): According to , the first bad commit is . That merge seems to include some wayland change and I'm using wayland, maybe it's related? Don't have time to bisect further (as it needs to rebuild the whole world) <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Can reproduce. Some initial triage notes: UI on non-Nvidia is okay Any use of Nvidia GPU seems to fail, including just rendering Crashes with Running with also crashes, so doesn’t seem to be a Wayland issue (GPU rendering also failing suggests the same) CPU rendering is fine I don’t have non-Nvidia GPUs capable of Blender GPU rendering to test those Initial search through upstream issues is not enlightening Runs okay with upstream’s compiled binary
Have identified a fix, will PR shortly.
Thanks! I think should go to BTW. I tested it locally and it fixes the issue
PR:
Change:
, libsndfile , pango , perl <ins> , python3 </ins> , gitUpdater }:

Discussion:
In the e16 (enlightenment) window manager, menus are not generated dynamically, but rather via a script called . The version build by current nixpkgs has the following issues on NixOS: The script fails to run from the menu, as it hard-codes the interpreter path as The script does not find files for most Nix-installed applications, as it does not search in , so even if the script is manually run with the menu is quite empty I'll be submitting an MR to address this problem, as I already have a locally-tested fix. Steps to reproduce the behavior: an X session with as the window manager error on launch that menus could not be generated The correct behaviour is that should run without error, and pick up any files for applications installed via Nix. The generated menu file should then populate the menu list with installed applications. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
<ins> { lib , stdenv , fetchFromGitHub , cmake , qtcharts , qttools , wrapQtAppsHook }: stdenv.mkDerivation rec { pname = "stacer"; version = "1.1.0"; src = fetchFromGitHub { owner = "oguzhaninan"; repo = pname; rev = "v${version}"; sha256 = "0qndzzkbq6abapvwq202kva8j619jdn9977sbqmmfs9zkjz4mbsd"; }; postPatch = '' substituteInPlace stacer/Managers/app_manager.cpp  --replace 'qApp->applicationDirPath() + "/translations"'  'QStandardPaths::locate(QStandardPaths::AppDataLocation, "translations", QStandardPaths::LocateDirectory)' ''; buildInputs = [ qtcharts qttools ]; nativeBuildInputs = [ cmake wrapQtAppsHook ]; preConfigure = '' lrelease stacer/stacer.pro ''; postInstall = '' install -Dm644 ../translations/*.qm -t $out/share/stacer/translations ''; meta = with lib; { description = "Linux System Optimizer and Monitoring"; homepage = "https://github.com/oguzhaninan/stacer"; license = licenses.gpl3Only; maintainers = with maintainers; [ dit7ya ]; platforms = platforms.linux; }; } </ins>

Discussion:
Project description Stacer is an open source system optimizer and application monitor that helps users to manage entire system with different aspects, its an all in one system utility. Metadata homepage URL: source URL: license: GPL-3.0 platforms: linux
Change:
services.udev.packages = [ pkgs.mate.mate-settings-daemon ]; services.gvfs.enable = true; services.upower.enable = config.powerManagement.enable; <ins> services.xserver.libinput.enable = mkDefault true; </ins> security.pam.services.mate-screensaver.unixAuth = true;

Discussion:
the touchpad space is mapped 1:1 to the screen, but the edge is missing, so you can't reach menus Steps to reproduce the behavior: computer with touchpad nixos with mate desktop to use touchpad working touchpad This is fixed with: please add it to like the other desktops do we should also check if it's missing for other desktops too and see if it's needed system: host os: multi-user?: sandbox: version: nixpkgs:
Change:
lib, fetchFromGitHub, fetchpatch, <del> pcsx2, </del> shaderc, }: <del> { </del> <ins> let </ins> pcsx2 = let self = { pname = "pcsx2"; <del> version = "2.1.17"; </del> <ins> version = "2.1.102"; </ins> src = fetchFromGitHub { <ins> pname = "pcsx2-source"; inherit (self) version; </ins> owner = "PCSX2"; repo = "pcsx2"; rev = "v${self.version}"; <del> hash = "sha256-yVao/8ZAssM0llKMR66fMbzsRL3WCkFyUk6ZD/MEaSc="; </del> <ins> hash = "sha256-OBxrdZVx6HbSFO6sc2D2HP6iYH3ZKDj+uEqM7cxZNm0="; </ins> }; }; in

Discussion:
Package name: pcsx2 Latest released version: 2.1.98 <!-- Search your package here: --- Current version on the unstable channel: 2.1.17 Current version on the stable/release channel: 1.7.5587 <!-- 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]:
As you wish:
Change:
meta = with lib; { description = "John the Ripper password cracker"; <del> license = licenses.gpl2Plus; </del> <ins> license = [ licenses.gpl2Plus ] ++ lib.optionals enableUnfree [ licenses.unfreeRedistributable ]; </ins> homepage = "https://github.com/openwall/john/"; maintainers = with maintainers; [ offline

Discussion:
See their : We neither remove the code nor pass the configuration option, so seems incorrect. I noticed this when glancing at cc
Change:
"ZXMPPROOT.cer" "ZoomLauncher" "config-dump.sh" <del> "qtdiag" </del> "timezones" "translations" "version.txt"

Discussion:
Zoom GUI is not shown on current master () This started to happen after package refactoring (, , ), and not due to package upgrade (I've checked that). I've documented some findings already ping and other Zoom users. Am I alone with this issue? At this moment no GUI (no greeting window) is shown. system: host os: multi-user?: sandbox: version: channels(root): channels(danbst): nixpkgs:
I at least cannot reproduce this with on nixpkgs
I installed to a profile using your reproduction steps, and it works fine here. What is in your in your shell? At least here it's:
I was able to reproduce this via: So there's some piece of the environment missing in the package.
This also reproduces the issue: Currently investigating what needs on the $PATH.
Thanks for your efforts, but when writing a command can you (and everyone else) please be complete? I had time to quickly confirm what you wanted to say, but here I am telling you that it is not a valid test case. I wrote an example of a complete command in closed thread with zoom in the title started by myself, so it's not like I don't practice this myself.
Sorry about that. As the package is unfree, you'll need in or in your environment. So a complete standalone test case would be:
does this reproduce issue too? I've checked that commit (last revision of old zoom-us expression) launches fine for me with this bash command.
It sounds like it was caused by using autoPatchelf? It could be that there is some incompatibility between what zoom-us is built with and what we have locally. Maybe we should just revert that part (but leave the version updates). I would much prefer to use Nixpkgs Qt here but there is a lot of unknown in how zoom-us is built. It might just be safest to revert to the old expression.
Turns out the issue was missing QML2 imports. This was discovered by comparing: to and looking for libraries loaded by the latter but not the former. One fix was to add a environment variable to the wrapper, but I found it simpler to re-use to build an environment with all the Qt dependencies symlinked in place and using its . The package should be easier to maintain as a result since you don't have to know what feature each qt5 package is meant to provide.
Change:
"@nerdwallet/shepherd" = pkgs.shepherd; # added 2023-09-30 "@nestjs/cli" = pkgs.nest-cli; # Added 2023-05-06 "@tailwindcss/language-server" = pkgs.tailwindcss-language-server; # added 2024-01-22 <ins> "@withgraphite/graphite-cli" = pkgs.graphite-cli; # added 2024-01-25 </ins> "@zwave-js/server" = pkgs.zwave-js-server; # Added 2023-09-09 alloy = pkgs.titanium-alloy; # added 2023-08-17 antennas = pkgs.antennas; # added 2023-07-30

Discussion:
Package name: Grahpite-cli Latest released version: 1.1.1 <!-- Search your package here: --- Current version on the unstable channel: 1.0.9 Current version on the stable/release channel: 1.0.9 <!-- 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. This package has no maintainer because it is a NPM package. might be related? Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Hello thanks for the request, I will try to go from node2nix to build from source as the issue linked suggestes
Giving a quick check to the graphite-cli repo linked in the npm package it is archived and "moved to your mono-repo" and also it is built with yarn so nor it can migrated to buildNpmPackage nor to building from source, so my guess is that it will need to still in node2nix
Please make a PR marking the package as unfree since their monorepo isn't publicly available.
As of right now graphite-cli is already unfree
Change:
with python3Packages; buildPythonApplication rec { pname = "kitty"; <del> version = "0.33.1"; </del> <ins> version = "0.34.0"; </ins> format = "other"; src = fetchFromGitHub { owner = "kovidgoyal"; repo = "kitty"; rev = "refs/tags/v${version}"; <del> hash = "sha256-E6gFGgySXs2oCS4Ipevbr9aPWzF4tb4Arl4w+4lQ+wg="; </del> <ins> hash = "sha256-IP1CWMHiWnBSbt+78EQ6hfX2A9FDhlwt0KLthXtO4dA="; </ins> }; goModules = (buildGo122Module { pname = "kitty-go-modules"; inherit src version; <del> vendorHash = "sha256-ypSZHJpk9wTXLH9sbmaSQB28iOIpv2nDPlgweM0Ldhs="; </del> <ins> vendorHash = "sha256-HNE0MWjL0PH20Glzb0GV6+lQu/Lslx8k/+YvlLHbHww="; </ins> }).goModules; buildInputs = [

Discussion:
Package name: kitty Latest released version: 0.34.0 <!-- Search your package here: --- Current version on the unstable channel: 0.33.1 Current version on the stable/release channel: 0.31.0 <!-- 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:
six ]; <del> patches = [ # Support for poetry-core, https://github.com/vlasovskikh/funcparserlib/pull/73 (fetchpatch { name = "support-poetry-core.patch"; url = "https://github.com/vlasovskikh/funcparserlib/commit/61ed558fc146b7a30879919325dfa8aae77be556.patch"; sha256 = "sha256-tqdR3r4/t7RWBYZeAabaN7oYf6VxkVVz006XICX9rYI="; }) ]; </del> pythonImportsCheck = [ "funcparserlib" ];

Discussion:
<!-- 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: 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.