jiebi/CodeConvo huggingface dataset:
Change:
services.colord.enable = mkDefault true; services.packagekit.enable = mkDefault true; hardware.bluetooth.enable = mkDefault true; <ins> services.hardware.bolt.enable = mkDefault true; </ins> services.xserver.libinput.enable = mkDefault true; # for controlling touchpad settings via gnome control center services.udev.packages = [ pkgs.gnome3.gnome-settings-daemon ]; systemd.packages = [ pkgs.gnome3.vino ];

Discussion:
As described in , GNOME 3 needs the to handle authenticating Thunderbolt 3 devices. This is not yet packaged for NixOS. I've bolt myself but have thus far been unsuccessful. Start a Gnome 3 session Navigate to Settings → Devices → Thunderbolt Expected Results: A nice GUI as . Actual Results: An error message: ! (Note: The error message is slightly misleading. Thunderbolt 3 is supported and working on my laptop, albeit with authorization disabled, but without GNOME doesn't know that.) system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can you share the errors you have encountered when packaging? Perhaps we can point you to solution.
Right now I'm hitting two roadblocks with bolt itself: the man pages fails somewhere inside asciidoc: I'm not sure how to get more information / further work on that. I disable manpage generation (), everything compiles and links just fine but then fails with:
Yeah, meson sometimes gives incredibly useless error messages. The problem is the build trying to install files in and , which it looks up through pkgconfig. Adding these fixes these: We'll also need to knock out as it tries to create a directory in . This fixed the build for me:
You can try to add flag to the asciidoc command in the meson file (I recommend setting to the local checkout of the project in question). As for the second error, Meson only calls when it fails to write to install destination, which means that some is probably wrong.
There ought to be a message Perhaps you can find it in build directory under if you run with .
Woohoo! ! Now I just have to: things up out how to get the systemd unit file linked out how to properly test a patch against this repo request!
We'll have to make module, something like this: Will probably need too.
Change:
soapyhackrf = callPackage ../applications/radio/soapyhackrf { }; <del> soapysdr = callPackage ../applications/radio/soapysdr { inherit (python3Packages) python numpy; }; </del> <ins> soapysdr = callPackage ../applications/radio/soapysdr { }; </ins> soapyremote = callPackage ../applications/radio/soapyremote { }; soapysdr-with-plugins = callPackage ../applications/radio/soapysdr { <del> inherit (python3Packages) python numpy; </del> extraPackages = [ limesuite soapyairspy

Discussion:
The soapysdr package contains a Python binding, but it is not possible to use it normally (e.g. via ) because it is not registered as a Python package in nixpkgs. I am not sure what is the proper way of handling this case, since soapysdr is both a regular library and a Python package, and nixpkgs makes a distinction between the two. A workaround is to add. Cc
See the section "15.17.2.2.4. toPythonModule function" in the Nixpkgs manual.
Change:
pythonPackages = python.pkgs; unwrapped = pythonPackages.buildPythonPackage rec { <del> name = "qtile-${version}"; </del> <ins> pname = "qtile"; </ins> version = "0.18.0"; src = fetchFromGitHub {

Discussion:
After running , the command shows the correct package but with the wrong version and description. Steps to reproduce the behavior: the reported version being and description being "A high-level dynamically-typed programming language" The version reported should state , and the description should read "A small, flexible, scriptable tiling window manager written in Python", as per ! It appears that the Qtile search has taken on the version and description of the Python version it depends on, as opposed to the items defined in the nix file.
ah yea, this was me
Change:
<del> { lib, stdenv , fetchFromGitLab , pkg-config , intltool , automake111x , autoconf , libtool , gnome2 , libxslt , python2 }: let version = "unstable-2019-02-13"; in stdenv.mkDerivation { pname = "planner"; inherit version; src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "GNOME"; repo = "planner"; rev = "76d31defae4979aa51dd37e8888f61e9a6a51367"; sha256 = "0lbch4drg6005216hgcys93rq92p7zd20968x0gk254kckd9ag5w"; }; nativeBuildInputs = with gnome2; [ pkg-config intltool automake111x autoconf libtool gnome-common gtk-doc scrollkeeper ]; buildInputs = with gnome2; [ GConf gtk libgnomecanvas libgnomeui libglade libxslt python2.pkgs.pygtk ]; # glib-2.62 deprecations NIX_CFLAGS_COMPILE = "-DGLIB_DISABLE_DEPRECATION_WARNINGS"; preConfigure = "./autogen.sh"; configureFlags = [ "--enable-python" "--enable-python-plugin" ]; enableParallelBuilding = true; meta = with lib; { homepage = "https://wiki.gnome.org/Apps/Planner"; description = "Project management application for GNOME"; longDescription = '' Planner is the GNOME project management tool. Its goal is to be an easy-to-use no-nonsense cross-platform project management application. Planner is a GTK application written in C and licensed under the GPLv2 or any later version. It can store its data in either xml files or in a postgresql database. Projects can also be printed to PDF or exported to HTML for easy viewing from any web browser. Planner was originally created by Richard Hult and Mikael Hallendal at Imendio. ''; license = licenses.gpl2Plus; platforms = platforms.all; maintainers = with maintainers; [ rasendubi amiloradovsky ]; }; } </del>

Discussion:
Describe the bug Expression: Debian has some downstream patches that switch it to python3 and gobject-introspection. The patches can be found in the original debian archive Here's the descriptions of the main patch. And there's several others that drop uses of deprecated dependencies. They have no plans to forward a lot of these patches, and they even mention this in the previous patch I mentioned. cc
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
PyGTK will be phased out with the transition to GTK+ version 3 and be replaced with PyGObject Here is an issue of upstream: So we can just wait for that and continue to use python2 or just remove the package.
I'm thinking it will likely be removed
I marked this as stale due to inactivity. &rarr;
Opened to remove planner
Change:
license = stdenv.lib.licenses.gpl2; <del> maintainers = [ ]; </del> <ins> maintainers = with lib.maintainers; [ lheckemann ]; </ins> platforms = stdenv.lib.platforms.mesaPlatforms; }; }

Discussion:
System: 17.03beta320. (Gorilla) Nix version: nix-env (Nix) 1.11.7 Nixpkgs version: "17.03beta320." ; also occurs on master.
You need to install SDL-1.2: After installing SDL, you may need to recompile pygame.
This isn't how Nix works — libraries aren't installed.
Try the following steps - they worked for me on a fresh VirtualBox. Step 1: Add the following lines (taken from ) to : Step 2: Install the environment: Step 3: Load the environment: Step 4: Download a sample PDF: Step 5: Open the PDF in Impressive:
Yep, that works, thanks for the input! However, this should not be the only way it works — particularly because myEnvFun is deprecated in favour of nix-shell. I'll see if I can fix the packaging. EDIT: works. So it'll be because ctypes uses gcc to discover library paths, which is a little insane IMHO but hey. I'll add a step in the patchPhase which inserts the full path to the SDL library rather than using ctypes's discovery.
Change:
enableParallelBuilding = true; <ins> passthru = { inherit openssl; }; </ins> meta = with lib; { description = "Small layer on top of PKCS#11 API to make PKCS#11 implementations easier"; homepage = "https://github.com/OpenSC/libp11";

Discussion:
pam_p11 causes login segfault in NixOS 22.11. GDM and Gnome lock screen are also affected. Steps to reproduce the behavior: to log in on the console or run `: Bug was not present in 22.05.
Reverting does not help.
Fixed by: Can someone with commit access apply this patch?
Can you open a pull request with that patch?
I hope that NixOS can be unbureaucratic enough that PRs are not required for this kind of patch.
It's generally preferred to do basically everything through PRs, so some basic CI checks can run & maintainers can be pinged automatically. We can just self-merge though. I created containing your diff and adding a comment for explanation.
This seems to be whats causing my 22.11-beta19 install on an Alder Lake 12700H (no gpu) to not boot into GDM. This is a pretty heinous issue that should be tested for. The graphical installer doesn't install Vim, WPA_Supplicant or anything useful for figuring out what went wrong, despite having Vim and WPA Supplicant available on the installation media/calamares.
Well I just did - you're welcome. That's what beta releases are for, aren't they?
Change:
then defaultBuildHostScope else assert pkgs.hostPlatform == pkgs.buildPlatform; defaultHostTargetScope; defaultHostHostScope = {}; # unimplemented <del> # TODO(@Ericson2314): we shouldn't preclude run-time fetching by removing # these attributes. We should have a more general solution for selecting # whether `nativeDrv` or `crossDrv` is the default in `defaultScope`. pkgsWithoutFetchers = lib.filterAttrs (n: _: !lib.hasPrefix "fetch" n) pkgs; targetPkgsWithoutFetchers = lib.filterAttrs (n: _: !lib.hasPrefix "fetch" n) pkgs.targetPackages; defaultHostTargetScope = pkgsWithoutFetchers // pkgs.xorg; defaultTargetTargetScope = targetPkgsWithoutFetchers // targetPkgsWithoutFetchers.xorg or {}; </del> <ins> defaultHostTargetScope = pkgs // pkgs.xorg; defaultTargetTargetScope = pkgs.targetPackages // pkgs.targetPackages.xorg or {}; </ins> splicer = pkgsBuildBuild: pkgsBuildHost: pkgsBuildTarget: pkgsHostHost: pkgsHostTarget:

Discussion:
I'm currently working on bringing up my cross-compilation environment. The latest issue is that fails to build when cross-compiling with: Note the name of the source archive: . The target suffix means that 's setup hooks fails to fire: It's not obvious to me how best to solve this. There are several options: generalize the setup hook (and others) to catch names with such suffixes the original filename to files fetch with and teach the unpacker hooks to use this instead of the derivation name teach the splicer not to add a suffix to source archives else
Pinging
and I discussed this via IRC, The conclusion is that we will simply avoid adding a host suffix for fixed-output derivations without host runtime dependencies (e.g. like source tarballs).
For the record, I work around this in bgamari/nixpkgs
Just was hit by this myself, is this still the preferred workaround?
I've never hit this personally, but should finish up. Feel free to give it a shot!
Change:
owner = "KapJI"; repo = "homeassistant-stubs"; rev = "refs/tags/${version}"; <del> hash = "sha256-lYoYU39/ayZb8Ue25a7uSN5x8tihzjj5mGaVKWPfa1w="; </del> <ins> hash = "sha256-bgXHEz8YuHcdGYzLpM7H8IVXixFC8Bz0i4SaatA49Qo="; </ins> }; nativeBuildInputs = [

Discussion:
Steps to reproduce the behavior: Home-Assistant service It started failing yesterday. It built fine a day before. It looks like for some reason 1.10.14 is dragged in as dependency event though 2.6.3 is now the default. I don't know Nix or Python well enough to figure out what exactly goes wrong. It looks like it's required for HACS (Home-Assistant Community Store) add-on, probably others as well. <!-- 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]:
nixpkgs . Perhaps it's because ..? I'm not really sure since it does seem to build fine with pydantic 2 here.
This won't really get maintainer attention unless they are tagged:
aiogithubapi pins sigstore<2, but that was unpinned in .
Change:
<del> From c7e2f6ed00c170b68d5d156faac38aa76d4490fd Mon Sep 17 00:00:00 2001 </del> <ins> From 9da2f2596db9f4f1a61825d82d9b8c3f3b2e99aa Mon Sep 17 00:00:00 2001 </ins> From: Nick Cao <nickcao@nichi.co> Date: Wed, 10 Jan 2024 20:58:20 -0500 Subject: [PATCH 2/2] skip failing and flaky tests

Discussion:
This is regarding hydra build failure. Thanks to a matrix user for pointing out the hydra link! Thank you! Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
xvfb_run file tesseract # tests are expecting tesseract 3.x precisely <del> ]; </del> <ins> ] ++ (with perlPackages; [ TestPod ]); </ins> checkPhase = '' <ins> # Temporarily disable a dubiously failing test: # t/169_import_scan.t ........................... 1/1 # #   Failed test 'variable-height scan imported with expected size' # #   at t/169_import_scan.t line 50. # #          got: '179' # #     expected: '296' # # Looks like you failed 1 test of 1. # t/169_import_scan.t ........................... Dubious, test returned 1 (wstat 256, 0x100) rm t/169_import_scan.t </ins> xvfb-run -s '-screen 0 800x600x24'  make test '';

Discussion:
Describe the bug in seems to be broken, in a way (I think) related to how other things have broken in the past, e.g. . From looking at examples of fixes, e.g. , it looks like it might be necessary to patch the Perl source in , but I don't really understand what's going on so I don't know how. To Reproduce Steps to reproduce the behavior: to for this package so that the tests actually run, as in my PR tests fail Expected behavior I tried making a package that depends on , and got the following error at runtime: Maintainer information:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . 3. Ask on the on .
Change:
psutil sentry-sdk setuptools <del> sip4 (pyqt5.override { withWebSockets = true; }) </del> <ins> sip (pyqt5.override { withWebSockets = true; }) </ins> truststore qt5.qtwayland ] ++ lib.optionals (pythonOlder "3.9") [

Discussion:
Steps to reproduce the behavior: gns3-gui-2.2.47 Add any other context about the problem here. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
seems to have the same issues as
cc
Change:
postPatch = '' substituteInPlace build.sh  --replace 'curl ${emojiJSON.url}' 'cat ${emojiJSON}' <ins> substituteInPlace wofi-emoji  --replace 'wofi' '${wofi}/bin/wofi'  --replace 'wtype' '${wtype}/bin/wtype'  --replace 'wl-copy' '${wl-clipboard}/bin/wl-copy' </ins> ''; buildPhase = ''

Discussion:
When and are not in system , script can't use them. Seems like is not enough. Maybe using or manually adding a PATH at the beginning of the script would fix the issue. Also the script is now in a fork: Edit: it has been updated in but not in . Steps to reproduce the behavior: the script without and in current PATH. won't type nor copy the emoji
Please check the PR I just opened. I'm getting locale errors, but that's an issue I have with my arch install :laughing:
Change:
}; <del> config = { services.xserver.displayManager.session = cfg.session.list; environment.systemPackages = mkIf cfg.session.needBGPackages [ pkgs.feh ]; # xsetroot via xserver.enable }; </del> <ins> xcfg.displayManager.session = cfg.session.list; </ins> }

Discussion:
Currently the DE is always enabled, see Because of that, feh is always to system PATH, in here: … because in here: … is always true, as the always contains , which doesn’t define . This whole code is totally pointless if we cannot turn off. Idea: let’s make optional, but by default turned on, not to break people’s setups. How I stumbled upon this? While configuring a machine for my mom, with Xfce enabled, I’ve noticed that feh is the default app for opening images, while it shouldn’t even be in . Turn on Xfce, open file manager, double click on a photo ⇒ feh opens instead of Xfce’s Ristretto. System: 16.03.1162. (Emu) Nix version: nix-env (Nix) 1.11.2 Nixpkgs version: "16.03.1162."
Still a problem in 18.03pre116054. (Impala). is the default photo viewer on my system.
This needs to be reopened.
Change:
services.udev.packages = [ cfg.package ]; boot.kernelModules = [ "i2c-dev" ] <del> ++ lib.optionals (cfg.motherboard == "amd") [ "i2c-piix" ] </del> <ins> ++ lib.optionals (cfg.motherboard == "amd") [ "i2c-piix4" ] </ins> ++ lib.optionals (cfg.motherboard == "intel") [ "i2c-i801" ]; systemd.services.openrgb = { description = "OpenRGB server daemon"; wantedBy = [ "multi-user.target" ]; serviceConfig = { <ins> StateDirectory = "OpenRGB"; WorkingDirectory = "/var/lib/OpenRGB"; </ins> ExecStart = "${cfg.package}/bin/openrgb --server --server-port ${toString cfg.server.port}"; Restart = "always"; };

Discussion:
The OpenRGB module () puts an configuration file and directory in the root of the filesystem. Steps to reproduce the behavior: the service I would expect the configuration to go into or something, and logs into . The current behaviour is surprising and works poorly with root-as-tmpfs configurations. This is the code responsible for working out where to put the OpenRGB config: (see also ) I suspect setting XDGCONFIGHOME or even just putting $PWD as would go some way towards fixing this.
looks like setting to something reasonable should do the trick. Kind of surprised this isn't the default behavior. ... after some searching... I guess it is the default behavior for user unit files, but currently we only have this packaged as a system unit file. I see two paths: Configure openrgb service as a user service (will require some work to get devices to be writable by user service) Just set to something reasonable like . Should probably set to be something similar incase they are following other XDG paths.
attempted to make a pr for this, githubs made it a nightmare so ill leave the relavent change here an unrelated to this issue change from that PR attempt is amd i2c module name is not
Change:
install -Dm644 "build/icon.png" "$out/share/icons/hicolor/256x256/apps/armcord.png" <del> makeShellWrapper "${lib.getExe electron_30}" "$out/bin/armcord"  </del> <ins> makeShellWrapper "${lib.getExe electron_31}" "$out/bin/armcord"  </ins> --add-flags "$out/share/lib/armcord/resources/app.asar"  "''${gappsWrapperArgs[@]}"  --add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations}}" 

Discussion:
Package name: armcord Latest released version: 3.3.0 <!-- Search your package here: --- Current version on the unstable channel: 3.2.8 Current version on the stable/release channel: 3.2.7 <!-- 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]:
Unstable is currently waiting on Electron 32 to be to nixpkgs to be able to update to 3.3.0. We may be able to update Stable before then since it is using the compiled packages. Which are you running currently (Stable vs Unstable)?
I'm currently using unstable.
Got it, once we have electron 32 available it should be a fairly quick package / release.
I attempted to package this using Electron 31 since that's available, and it seems to be working stably. I looked at the ArmCord source and it doesn't look like it relies on anything Electron 32-specific, so I'll try to put out a PR.
Change:
export NIX_${ghcCommandCaps}="${ghcEnv}/bin/${ghcCommand}" export NIX_${ghcCommandCaps}PKG="${ghcEnv}/bin/${ghcCommand}-pkg" export NIX_${ghcCommandCaps}_DOCDIR="${ghcEnv}/share/doc/ghc/html" <del> export NIX_${ghcCommandCaps}_LIBDIR="${ghcEnv}/lib/${ghcEnv.name}" </del> <ins> export NIX_${ghcCommandCaps}_LIBDIR="${ghcEnv}/lib/${ghcCommand}-${ghc.version}" </ins> ${shellHook} ''; };

Discussion:
The shell hook in the attribute of a derivation sets with the ghc derivation full name, rather than just the executable name and numeric version. This isn't usually noticed because the ghc itself is wrapped with a wrapper which provides these correctly. Tools such as fail to work in this environment though. Run: Observe that the directory printed does not exist. Nixpkgs version: "17.03pre96205."
Change:
"-DFETCHCONTENT_QUIET=OFF" "-DFETCHCONTENT_SOURCE_DIR_ABSEIL_CPP=${abseil-cpp.src}" "-DFETCHCONTENT_SOURCE_DIR_DATE=${howard-hinnant-date}" <del> "-DFETCHCONTENT_SOURCE_DIR_EIGEN=${eigen}" </del> "-DFETCHCONTENT_SOURCE_DIR_FLATBUFFERS=${flatbuffers}" "-DFETCHCONTENT_SOURCE_DIR_GOOGLE_NSYNC=${nsync.src}" "-DFETCHCONTENT_SOURCE_DIR_MP11=${mp11}" <del> "-DFETCHCONTENT_SOURCE_DIR_ONNX=${python3Packages.onnx.src}" </del> <ins> "-DFETCHCONTENT_SOURCE_DIR_ONNX=${onnx}" </ins> "-DFETCHCONTENT_SOURCE_DIR_PYTORCH_CPUINFO=${pytorch_cpuinfo}" "-DFETCHCONTENT_SOURCE_DIR_RE2=${re2.src}" "-DFETCHCONTENT_SOURCE_DIR_SAFEINT=${safeint}"

Discussion:
Meaningful errors Full logs: system: host os: multi-user?: sandbox: version: channels(root): channels(jarrod): nixpkgs: Source file with issue:  I tried to locate where is defined, but was unable to.
Edited the issue and I'm not sure if GitHub retroactively sends notifications, so pardon the double-mention:
Will be fixed by .
Change:
ninja gfortran ] ++ lists.optionals cudaSupport [ <del> cudaPackages.cuda_nvcc </del> <ins> effectiveCudaPackages.cuda_nvcc </ins> ]; buildInputs = [

Discussion:
Build of failed on x86_64-linux as of . This is currently breaking . python3Packages.torchvision maintainers cc: magma maintainers cc: Other cc: n/a nixpkgs at commit Contents of : This issue was automatically generated by . that created this issue. Internal tags: - -
Will be closed by