jiebi/CodeConvo huggingface dataset:
Change:
argyllcms wxPython numpy <ins> dbus-python </ins> ]; nativeBuildInputs = [

Discussion:
Describe the bug DisplayCal, an application for calibrating one's monitor, is not functional in 20.03, though it builds. To Reproduce Steps to reproduce the behavior: displaycal in a calibration device the "Profile and Calibrate" button near the bottom of the GUI can not find the package and refuses to continue. Expected behavior DisplayCal should move to the next screen and start the calibration process. Additional context The package builds, but does not function. The 3.5 version that is packaged is pretty far out of date, so I've started to try and update the package , but the compilation fails. I have a calibration device and am looking for help to get this working. Notify maintainers
sampson in IRC suggested the following patch, but the build still fails at the same point for me: The error when building the package is:
I can get the package to build now, but it doesn't run:
It says , i guess you have to add to the , like you have done with .
you are correct. Now DisplayCal builds, launches, and finds my calibraiton devices. I'll have to test this on my full NixOS install, instead of my Ubuntu machine with nixpkg. Thank you for your help!
Change:
owner = "GreycLab"; repo = "gmic"; rev = "v.${finalAttrs.version}"; <del> hash = "sha256-HagGabJ1jkg5SkMlr0Y5rGFw64jPW8QLuR0I2idM1N0="; </del> <ins> hash = "sha256-881+o6Wz4yNf92JNNLQn9x44SSjXAp/cZLkBGCfM6DY="; </ins> }; # TODO: build this from source <del> # Reference: src/Makefile, directive gmic_stdlib.h </del> <ins> # Reference: src/Makefile, directive gmic_stdlib_community.h </ins> gmic_stdlib = fetchurl { <del> name = "gmic_stdlib.h"; url = "http://gmic.eu/gmic_stdlib${lib.replaceStrings ["."] [""] finalAttrs.version}.h"; hash = "sha256-7JzFU4HvAtC5Nz5vusKCnJ8VMuKfSi1yFmjj0Hh+vA4="; </del> <ins> name = "gmic_stdlib_community.h"; url = "http://gmic.eu/gmic_stdlib_community${lib.replaceStrings ["."] [""] finalAttrs.version}.h"; hash = "sha256-UZzCAs+x9dVMeaeEvPgyVZ5S6UO0yhJWVMgBvBiW2ME="; </ins> }; nativeBuildInputs = [

Discussion:
Package name: gmic Latest released version: 3.3.5 Current version on the unstable channel: 3.3.1 Current version on the stable/release channel: 3.3.1 Notify maintainers 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:
minidlna = handleTest ./minidlna.nix {}; miniflux = handleTest ./miniflux.nix {}; minio = handleTest ./minio.nix {}; <ins> miracle-wm = runTest ./miracle-wm.nix; </ins> miriway = handleTest ./miriway.nix {}; misc = handleTest ./misc.nix {}; mjolnir = handleTest ./matrix/mjolnir.nix {};

Discussion:
Project description A Mir-based Wayland compositor like , but tiling instead of floating. ! More Mir testers, more better. Requesting this from myself so I don't forget about this. Needs a very new Mir, newer than we currently provide (depends on ). Metadata homepage URL: source URL: license: gpl3+ platforms: linux Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
# Open the chosen ports for UDP. networking.firewall.allowedUDPPorts = <del> unique (mapAttrsToList (netName: netCfg: netCfg.listen.port) enabledNetworks); </del> <ins> unique (filter (port: port > 0) (mapAttrsToList (netName: netCfg: resolveFinalPort netCfg) enabledNetworks)); </ins> # Create the service users and groups. users.users = mkMerge (mapAttrsToList (netName: netCfg:

Discussion:
When a "lighthouse" and a regular "roaming" node are on the same network and the default value for () is used, nodes occasionally enter a consistent failure state while trying to connect. I suspect this occurs when Nebula tries to NAT-punch with the local router and always tries to connect to the lighthouse instead of the roaming node. Steps to reproduce the behavior: up a lighthouse node and roaming node -forward port 4242 for the lighthouse node to set a value for in the Nebula config intermittent failures The value of should be required, with a link to Nebula docs: I'm not entirely sure, but logs from the issue indicate the lighthouse-node handshakes are both sending packets to "192.168.1.1:4242", which is port-forwarded to the lighthouse (I'm in a dual-NAT setup unfortunately; this is the IP of the outer NAT). Explicitly setting the port to (to automatically select an ephemeral port) on the roaming nodes immediately fixes the issue. (wrote the initial module with the port default) Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Based on those docs, I think we can solve this without requiring the user to specify the port. Since we know whether a node is a lighthouse via , we could implement a behavior where defaults to for lighthouses and for non-lighthouses: I'm not sure how to get the for this, though. Maybe if the options were , then we could just refer to ? We'd probably also want to include . Thoughts?
My thought is that a change should meet the following requirements: Per set and to something like:Set the actual value appropriately in the module with an expression like the above if the input is null. If (isLighthouse or isRelay) and the final port evaluates to 0, we should warn, since this config will probably result in connectivity issues. There should be a test for this. I am split on whether to backport this. While this is a bug, people may have relied on the default port to NAT port forward from routers to a Nebula node that is not a lighthouse or a relay.

As such the new default may impede connectivity on restrictive NATs, so this is also a breaking change.
Also, good job diagnosing this. I think I've run into this before but didn't know what was causing it.
Per (captured in + ) Given this, it is probably a good idea to both fix and backport this.
Change:
<ins> { lib, buildPythonPackage, fetchFromGitHub, pytestCheckHook, pythonOlder, pythonAtLeast, setuptools, distutils, }: buildPythonPackage rec { pname = "tree-sitter"; version = "0.21.3"; pyproject = true; disabled = pythonOlder "3.7"; src = fetchFromGitHub { owner = "tree-sitter"; repo = "py-tree-sitter"; rev = "refs/tags/v${version}"; hash = "sha256-HT1sRzDFpeelWCq1ZMeRmoUg0a3SBR7bZKxBqn4fb2g="; fetchSubmodules = true; }; build-system = [ setuptools ]; nativeCheckInputs = [ pytestCheckHook ]; pythonImportsCheck = [ "tree_sitter" ]; # Needed explicitly for Python >= 3.12 as tree-sitter provides # calls to distutils functions to compile language files dependencies = lib.optionals (pythonAtLeast "3.12") [ distutils ]; preCheck = '' rm -r tree_sitter ''; meta = with lib; { description = "Python bindings to the Tree-sitter parsing library"; homepage = "https://github.com/tree-sitter/py-tree-sitter"; changelog = "https://github.com/tree-sitter/py-tree-sitter/releases/tag/v${version}"; license = licenses.mit; maintainers = with maintainers; [ fab ]; }; } </ins>

Discussion:
Steps to reproduce the behavior: Originally found building Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
That's not a build failure, but an evaluation failure. If you want to make not depend on , you need to figure out where does this dependency comes from, and try to remove it. The reason we disabled is documented in the code: Note that although the issue is fixed, we intentionally provide an expression for , so that we can build with it. See also: You can work around this issue by using instead, or try to be creative and make depend on the latest (and not ), by fixing the upstream issue . Good luck!
I'm closing this, as this is an upstream issue. Ideally it would have been possible to declaratively write with Nix why packages are disabled for certain Python implementation, and that would have improved the evaluation failure message you observed. I think I saw discussion about such a feature, but I can't find any links now unfortunately.
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
{ lib, <ins> go_1_23, </ins> buildGoModule, fetchFromGitHub, installShellFiles,

Discussion:
Package name: Latest released version: 0.28.0 <!-- Search your package here: --- Current version on the unstable channel: 0.27.0 Current version on the stable/release channel: N/A <!-- 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! --- There is an old one for updating to 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]:
I tried doing this myself but can't get it to build as the new version request Golang 1.23 and I couldn't work out how to get nix to build with that.
Change:
<ins> { lib , stdenv , sassc , gdk-pixbuf , glib , gobject-introspection , librsvg , gtk3 , python3 , fetchFromGitHub , wrapGAppsHook }: let py = python3.withPackages (p: [ p.pygobject3 ]); pname = "themix-gui"; version = "1.15.1"; in stdenv.mkDerivation { inherit pname version; src = fetchFromGitHub { owner = "themix-project"; repo = "themix-gui"; rev = version; hash = "sha256-xFtwNx1c7Atb+9yorZhs/uVkkoxbZiELJ0SZ88L7KMs="; fetchSubmodules = true; }; nativeBuildInputs = [ gobject-introspection py sassc wrapGAppsHook ]; buildInputs = [ gdk-pixbuf glib gtk3 librsvg py ]; postPatch = '' substituteInPlace gui.sh packaging/bin/{oomox,themix}-gui --replace python3 ${lib.getExe py} ''; dontBuild = true; installPhase = '' runHook preInstall make DESTDIR=/ APPDIR=$out/opt/oomox PREFIX=$out install_gui install_import_xresources install_export_xresources python -O -m compileall $out/opt/oomox/oomox_gui -d /opt/oomox/oomox_gui runHook postInstall ''; meta = { description = "Graphical application for designing themes and exporting them using plugins"; longDescription = '' Graphical application for generating different color variations of Oomox (Numix-based) and Materia (ex-Flat-Plat) themes (GTK2, GTK3, Cinnamon, GNOME, Openbox, Xfwm), Archdroid, Gnome-Color, Numix, Papirus and Suru++ icon themes. Have a hack for HiDPI in gtk2. Its Base16 plugin also allowing a lot of app themes support like Alacritty, Emacs, GTK4, KDE, VIM and many more. ''; homepage = "https://github.com/themix-project/themix-gui"; license = lib.licenses.gpl3Only; mainProgram = "themix-gui"; maintainers = with lib.maintainers; [ eclairevoyant ]; platforms = lib.platforms.linux; }; } </ins>

Discussion:
Project description Graphical application for generating different color variations of a Materia and Oomox themes (GTK2, GTK3 and others), Archdroid, Gnome-Colors, Numix, Papirus, Suru++ icons, and terminal palette. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Change:
PULSE_SERVER="''${PULSE_SERVER:-}"  PULSE_COOKIE="''${PULSE_COOKIE:-}"   <del> MOZ_ENABLE_WAYLAND=$MOZ_ENABLE_WAYLAND  WAYLAND_DISPLAY="$WAYLAND_DISPLAY"  XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR"  XCURSOR_PATH="$XCURSOR_PATH"  </del> <ins> MOZ_ENABLE_WAYLAND="''${MOZ_ENABLE_WAYLAND:-}"  WAYLAND_DISPLAY="''${WAYLAND_DISPLAY:-}"  XDG_RUNTIME_DIR="''${XDG_RUNTIME_DIR:-}"  XCURSOR_PATH="''${XCURSOR_PATH:-}"  </ins>  APULSE_PLAYBACK_DEVICE="''${APULSE_PLAYBACK_DEVICE:-plug:dmix}"  

Discussion:
On startup, Tor Browser doesn't start if some variables about Wayland aren't set. Steps to reproduce the behavior: and (if set) Tor Browser in a terminal and see the error message. Tor Browser should start. This issue was caused by . currently does not fix the problem. In the meantime, an easy fix would be : <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Notifying peoples from the aforementioned PRs instead. Please run and paste the result.
I can confirm this issue
thanks !
Change:
cargoSha256 = "1cfdwf00jgwsv0f72427asid1xr57s56jk5xj489dgppvgy7wdbj"; <del> cargoBuildFlags = [ "--features=dist-client,dist-server" ]; </del> <ins> cargoBuildFlags = lib.optionals (!stdenv.isDarwin) [ "--features=dist-client,dist-server" ]; </ins> nativeBuildInputs = [ pkg-config ]; buildInputs = [ openssl ] ++ lib.optional stdenv.isDarwin Security;

Discussion:
Describe the bug It looks like the was to the package, which is Linux-only. Later, a PR was accepted that marked the entirety of as Linux-only when it absolutely works on macOS and probably (though I don't run them) BSD variants. This seems like an incorrect way to include the utility and instead should have been included as a separate package to avoid breaking this package for non-Linux operating systems. To Reproduce Steps to reproduce the behavior: on a macOS machine with an up-to-date unstable channel. Expected behavior should be installable on its supported platforms, in this case . Metadata Please run and paste the result. Maintainer information:
Build currently fails on darwin:
Related:
Change:
<ins> --- /dev/null	2024-03-29 17:01:59.989114590 +0100 +++ cli/Cargo.lock	2024-04-17 13:27:32.243365234 +0200 @@ -0,0 +1,7 @@ +# This file is automatically @generated by Cargo. +# It is not intended for manual editing. +version = 3 + +[[package]] +name = "kclvm_cli" +version = "0.8.7" </ins>

Discussion:
After installation kcl-cli shell completion is not available. Steps to reproduce the behavior: kcl-cli completion Shell completion should be installed. N/A N/A <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
rm priority/ioprio_test.go # tries to set nice(2) IO priority rm restic/downloader_test.go # tries to use network rm schedule/schedule_test.go # tries to use systemctl <del> # `config/path_test.go` expects `$HOME` to be the same as `~nixbld` which is `$NIX_BUILD_TOP` export HOME="$NIX_BUILD_TOP" # `util/tempdir_test.go` expects `$HOME/.cache` to exist mkdir "$HOME/.cache" </del> <ins> rm config/path_test.go # expects normal environment rm util/tempdir_test.go # expects normal environment </ins> ''; installPhase = ''

Discussion:
Steps to reproduce the behavior: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
srt systemd taglib <del> xlibsWrapper </del> zlib ] ++ (with xorg; [ <ins> libSM </ins> libXpm libXv libXvMC

Discussion:
In I noticed unusual behaviour of when is overridden. That PR handles override part. But I think should just disappear. Where should be no reason (for example) for to depend on at build time. is just the wrapper around a few libraries. Quoting : Mechanically we can replace with the list of packages it provides. Even better would be to audit needed libraries for each user and use only a subset of them. Example fix: [x] perlPackages.X11Protocol: [x] pulseaudio: More packages to fix: [x] Xaw3d: [x] emacs: [x] fox16: [x] geant4: [x] [x] gtk2: [x] [x] haskellPackages.greenclip: [x] [x] lesstif: [x] monotoneViz: [x] motif: [x] mythtv: [x] ocaml- [x] [x] [x] pypy2, pypy3: [x] qgis: [x] qgis-ltr: [x] [x] qt6Packages.qtwayland: [x] rPackages.Cairo: [x] rPackages.devEMF: [x] [x] rPackages,rgl: [x] tightvnc: [x] weston: Fixed packages: [x] astromenace: [x] catclock: [x] clanlib: [x] conky: [x] elinks: [x] fox: [x] freeglut: [x] ghostscript, ghostscriptX: [x] gnome2.libgnomeui: [x] glbinding: [x] glew, glew-egl: [x] glew110: [x] imhex: [x] imlib2,

imlib2Full: [x] ion3: [x] libagar: [x] libstroke: [x] lirc: [x] mitschemeX11: [x] ncview: [x] nedit: [x] notion: [x] oneko: [x] openrw: [x] pasystray: [x] pcb: [x] povray: [x] pythonFull: [x] qemacs: [x] qmmp: [x] rss-glx: [x] scrot: [x] soxt: [x] survex: [x] synergy: [x] ted: [x] unclutter: [x] unclutter-xfixes: [x] vlc: [x] voxelands: [x] wordnet: [x] xautolock: [x] xfe: [x] x11sshaskpass: [x] xfig: [x] xidlehook: [x] xine-ui: [x] xinputcalibrator: [x] xmountains: [x] xspim: [x] xtrlock-pam: [x] xwinwrap: [x] xxgdb: [x] zoom:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
<ins> { lib, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "goread"; version = "1.6.5"; src = fetchFromGitHub { owner = "TypicalAM"; repo = "goread"; rev = "v${version}"; hash = "sha256-SRVXcdgtRpWqvO28CnUcx40nFJnG+Hd94Ezgaj5xK6A="; }; vendorHash = "sha256-/kxEnw8l9S7WNMcPh1x7xqiQ3L61DSn6DCIvJlyrip0="; env.TEST_OFFLINE_ONLY = 1; meta = { description = "Beautiful program to read your RSS/Atom feeds right in the terminal"; homepage = "https://github.com/TypicalAM/goread"; changelog = "https://github.com/TypicalAM/goread/releases/tag/v${version}"; license = lib.licenses.gpl3Plus; mainProgram = "goread"; maintainers = with lib.maintainers; [ schnow265 ]; }; } </ins>

Discussion:
Project description goread is an RSS/Atom feed reader for your terminal. It allows you to categorize and follow feeds and read articles right in the terminal. Metadata homepage URL: source URL: license: gpl3 platforms: unix, linux, darwin Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Change:
{ lib , ddcutil , gjs <ins> , gnome , gobject-introspection </ins> , xprop , touchegg <ins> , vte , wrapGAppsHook </ins> }: let # Helper method to reduce redundancy

Discussion:
Describe the bug The "ddterm" extension does not work, because it lacks some NixOS-specific packaging magic having to do with , typelibs etc (I don't understand anything about it, just keyword-googled ) To Reproduce Steps to reproduce the behavior: to into Gnome F12 visible happens. "/run/current-system/sw/share/gnome- line 5: exec: gjs: not found" appears in the user journal Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(cmm): channels(root): nixpkgs: Maintainer information:
Would need patching to hardcode the GJS path.
note that adding to does not serve as a workaround, because then it fails due to not finding typelibs. so I'm not sure just patching in the path to will solve this.
Yeah, will need at least in and , , and in .
You can try
still cannot find the Vte typelib, whatever that is. I'll have to let the experts sort it out :)
If vte is used by the extension itself, not just by the program it executes, it will need something like
still broken on 21.11
As far as I can tell, VTE is not used by the extension itself. They do the required modules at runtime. My patch currently looks like this:
that's an improvement, but with it I still get (in a nice Zenity window this time):
only applies to stuff in and by default so will not actually get wrapped.
if I'm reading the of correctly, "by default" actually means "hard-coded, nothing you can do short of changing itself", right?
You can still use in .
After processing, the script looks like this: does not appear anywhere in this (although I think it should), and consequentially the error does not go away.
thanks for the hints folks! this overlay finally results in working ddterm here:
That's great to hear. Is the still needed though? Also, would you like to open a pull request fixing this? (Start in )
I thought you need to have in the build inputs so that the shell function is available?
You probably also need in the so that is picked up into automatically.
yup, that also works, pull amended
Change:
enableParallelBuilding = true; <del> nativeBuildInputs = [ pkgconfig ]; buildInputs = [ python libxml2Python libxslt which libX11 xkeyboard_config isocodes itstool wayland gtk3 glib intltool gnome_doc_utils libxkbfile libseccomp gobjectIntrospection ]; </del> <ins> nativeBuildInputs = [ pkgconfig which itstool intltool libxslt gnome_doc_utils gobjectIntrospection ]; buildInputs = [ python libxml2Python libX11 bubblewrap xkeyboard_config isocodes wayland gtk3 glib libxkbfile libseccomp ]; </ins> propagatedBuildInputs = [ gnome3.gsettings_desktop_schemas ]; <ins> patches = [ ./bubblewrap-paths.patch ]; postPatch = '' substituteInPlace libgnome-desktop/gnome-desktop-thumbnail-script.c --subst-var-by  BUBBLEWRAP_BIN "${bubblewrap}/bin/bwrap" ''; </ins> meta = with stdenv.lib; { platforms = platforms.linux; maintainers = gnome3.maintainers;

Discussion:
Once you take a video with cheese (as webm), a few strange things happen: No thumbnails for images or videos will load. Cheese will refuse to close without a 'kill/killall .cheese-wrapped' Errors: video in cheese. cheese via 'Quit' button OR by closing the window Check (cheese will still be running) and taking up quite a bit of CPU. Normal behavior is returned once webm file is moved or deleted. Cheese doesn't understand webm yet tries to record as webm. Then every attempt at loading the webm in the preview pane causes an error. Maybe a dependency issue and we should depend on some webm support library? Or an upstream issue with Cheese itself? System: 16.09.1445. (Flounder); 16.03.885. (Emu) Nix version: nix-env (Nix) 1.11.4; nix-env (Nix) 1.11.2 Nixpkgs version: 16.09.1445.; 16.03.885. Cheese version: 3.20.2; 3.18.1
Updated. Still an issue in 16.09.
I can reproduce the problems with thumbnails and webm-related issues on 17.03 and master. It doesn't seem to crash on exit in my testing. Playing with gets problems with missing to disappear, adding gstreamer bits (like is done in totem or sushi) doesn't seem to be sufficient (I'm no expert here). Related: (?).
I opened an upstream issue:
Running cheese with environment variable revealed missing path to bubblewrap. After patching , user still needs to have thumbnailers ( and ) installed, for now I have them as dependencies like I did in . The infinite loop is still an upstream bug but with thumbnailers, it at least should not appear.
Change:
<ins> { lib , mkXfceDerivation , glib , gtk3 , libxfce4ui , libxfce4util , xfce4-panel , xfconf , libwnck , exo }: mkXfceDerivation { category = "panel-plugins"; pname = "xfce4-docklike-plugin"; version = "0.4.1"; sha256 = "sha256-BKxd2TFEbRHeFy/dC2Wx5ppErsi7d2m7JicFCcZbjTo="; buildInputs = [ glib gtk3 libxfce4ui libxfce4util xfce4-panel xfconf libwnck exo ]; NIX_CFLAGS_COMPILE = "-I${glib.dev}/include/gio-unix-2.0"; meta = with lib; { homepage = "https://docs.xfce.org/panel-plugins/xfce4-docklike-plugin/start"; description = "A modern, minimalist taskbar for Xfce"; license = licenses.gpl3; platforms = platforms.linux; maintainers = with maintainers; [ ] ++ teams.xfce.members; }; } </ins>

Discussion:
Project description A modern, minimalist taskbar for Xfce. Docklike Taskbar behaves similarly to many other desktop environments and operating systems. Wherein all application windows are grouped together as an icon and can be pinned to act as a launcher when the application is not running. Commonly referred to as a dock. Metadata homepage URL: source URL: license: gpl3 platforms: linux
Hi I submitted xfce4-docklike-plugin for review. Feel free to provide feedback.