jiebi/CodeConvo huggingface dataset:
Change:
#       That way it would never matter whether vioserial is installed from win-virtio or win-spice. copy_vioserial = arch: "mkdir -p $out/${arch}/vioserial; cp ${win-virtio}/${arch}/vioserial/* $out/${arch}/vioserial/. n"; copy = arch: version: (copy_qxl arch version) + (copy_usbdk arch) + (copy_vdagent arch) + (copy_vioserial arch); <del> in (copy "amd64" "w8.1") + (copy "x86" "w8.1"); </del> <ins> in '' runHook preInstall ${(copy "amd64" "w10") + (copy "x86" "w10")} runHook postInstall ''; </ins> meta = with lib; { description = "Windows SPICE Drivers";

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 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: win-virtio <!-- The current version can be found easily with the same process than 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: 0.1.141-1 desired version: 0.1.204-1 maintainers: Hi Linus, the original maintainer---Thomas Strobel---appears to be unavailable on GH, so I just tagged you since you made the last version update a few years ago. I'll submit a PR for this myself though.
Good catch, and thanks for the ping :) I think 0.1.141-1 was the stable version at the time, not sure if we want stable or latest? I don't really mind either way though.
Why not package both?
Good point. Using stable seems sensible in this case, it looks like very little time has elapsed between them anyway so I doubt there's much value in bumping to latest. I'll stick with that if there's no objection.

name: win-spice <!-- The current version can be found easily with the same process than 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: 0.11 desired version: 0.21 Note that this is a collection of components with separate version numbers, the package version is taken only from one of them. The following updates also should be made: qxlwddm: 0.11 -0.21 usbdk: 1.0.4 -1.0.22 vdagent: 0.7.3 -0.10.0 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Hi Fortune, the original maintainer---Thomas Strobel---appears to be unavailable on GH, so I just tagged you since you fixed the 7z issue recently. I'll submit a PR for this myself though.
Change:
<ins> { appimageTools, lib, fetchurl, }: let pname = "nuclear"; version = "0.6.31"; src = fetchurl { # Nuclear currenntly only publishes AppImage releases for x86_64, which is hardcoded in # the package name. We also hardcode the host arch in the release name, but should upstream # provide more arches, we should use stdenv.hostPlatform to determine the arch and choose # source URL accordingly. url = "https://github.com/nukeop/nuclear/releases/download/v${version}/${pname}-v${version}-x86_64.AppImage"; hash = "sha256-ezho69fDP4OiLpC8KNKc8OIZ++TX4GUinFB6o8MLx3I="; }; appimageContents = appimageTools.extract { inherit pname version src; }; in appimageTools.wrapType2 { inherit pname version src; extraInstallCommands = '' install -m 444 -D ${appimageContents}/${pname}.desktop -t $out/share/applications substituteInPlace $out/share/applications/${pname}.desktop  --replace-fail 'Exec=AppRun' 'Exec=${pname}' cp -r ${appimageContents}/usr/share/icons $out/share ''; meta = { description = "Streaming music player that finds free music for you"; homepage = "https://nuclear.js.org/"; license = lib.licenses.agpl3Plus; maintainers = [ lib.maintainers.NotAShelf ]; platforms = [ "x86_64-linux" ]; mainProgram = "nuclear"; }; } </ins>

Discussion:
Package name: nuclear Latest released version: 0.6.31 Current version on the unstable channel: 0.6.30 Current version on the stable/release channel: 0.6.30 <!-- 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]:
Made a PR, would appreciate it if you tested it - I don't use nuclear very often at the moment.
Change:
}; font = mkOption { <del> type = with types; either str path; </del> <ins> type = with types; nullOr (either str path); </ins> default = "Lat2-Terminus16"; example = "LatArCyrHeb-16"; description = mdDoc ''

Discussion:
NixOS's default kernel configuration only enables the 8x8 and 8x16 fonts. This is not ideal, because they are too small for high-resolution displays. The current workaround used by is to set . There are problems with this however: during early boot, before the GPU drivers are loaded, the firmware or bootloader may initialize the display at a lower resolution, resulting in an oversized font in fact, the hidpi module sets , which in my opinion is a bad idea, because it will force switching to a low resolution when the firmware could have set us up with a high-res framebuffer; this also breaks seamless boot for those who care (sd-boot's default is to keep the mode unchanged) resolution switches reset the font to the kernel default, and under certain circumstances it seems a race condition can prevent userspace from setting the font correctly again The kernel is actually able to select an appropriate font for the current resolution using a simple heuristic since mid-2019 (). This bypasses the problems listed above and ensures a good font is always selected after resolution switches. The only requirement appears to be that the fonts must be built into the kernel. Font-related kconfig options as configured by NixOS: Arch Linux: So Arch enables the default 8x16 and Terminus 16x32 (the same font that the hidpi module sets). The observed behavior on Arch is that it seamlessly switches fonts after mode switches, and I've never seen this break since it has been enabled.
Same issue here with a NVIDIA card and a 3840x1600 monitor. tty0 console text covers the entire screen. I couldn't resolve this issue manually with and (DP-3 is my monitor). Setting the font manually to the default value () gives the right font size but this particular font doesn't have antialiasing which looks quite bad on a HIDPI monitor.
There's no antialiasing in console fonts, they're all bitmap fonts.
Gotcha, thanks. On side note, I looked for a different consolefont and came up with this. Looks a lot better now :smile:
Change:
{stdenv, fetchurl, qtbase, qtx11extras, ncurses, xorg, zlib, python27Packages}: stdenv.mkDerivation { <del> name = "fdr-4.2.0"; </del> <ins> name = "fdr-4.2.3"; </ins> src = fetchurl { <del> url = https://www.cs.ox.ac.uk/projects/fdr/downloads/fdr-3754-linux-x86_64.tar.gz; sha256 = "d24492485db9b8b95c62c53a6396094f836ee079cfc743688a397503c3ec9bf8"; </del> <ins> url = https://www.cs.ox.ac.uk/projects/fdr/downloads/fdr-3789-linux-x86_64.tar.gz; sha256 = "0n2yqichym5xdawlgk3r7yha88k7ycnx6585jfrcm7043sls1i88"; </ins> }; libPath = stdenv.lib.makeLibraryPath [

Discussion:
Install fdr, run fdr4 System: (NixOS: , Ubuntu/Fedora: , ...) Nix version: 18.03pre118366. (Impala) version: 18.03pre118366. Sandboxing enabled: yes
Change:
gegl ]; <del> pythonPath = [ pygtk ]; </del> # Check if librsvg was built with --disable-pixbuf-loader. PKG_CONFIG_GDK_PIXBUF_2_0_GDK_PIXBUF_MODULEDIR = "${librsvg}/${gdk-pixbuf.moduleDir}";

Discussion:
Describe the bug GIMP uses Python and GTK+ for e.g. plugins. But GIMP in the NixOS-GIMP-package cannot find the Python-gtk-module: GIMP itself starts, but e.g. some plugins cannot be used, e.g. . When selecting this plugin, nothing happens, and the following error is shown in the console (again): To Reproduce Steps to reproduce the behavior: GIMP. GIMP. at the error-messages. Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
Can confirm this still doesn't work. Of note is that installing will allow when used from the REPL, but GIMP will still not recognize it. Tagging since they are tagged as the maintainer.

I see the following warnings when running gimp: Not sure if they are critical or not. I do have problems with one Python plugin, not sure if this could be related. Run gimp from the terminal. I'm running it from i3+none desktop environment, if that matters. Please run and paste the results.
I can see the warning too. This is what the file looks like on Arch: nothing special compared to ours: The file exists and is executable Not really sure what is wrong. Also the Python scripts seem to work, at least does.
For me, resynthesizer runs but it doesn't produce correct results:
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly: for maintainers and people that previously touched the related code and @ mention them in a comment. on the . on the on .
Still important to me. This is the current console output:
I have found this issue can be fixed by installing the python package by yourself (which is weird: it looks like GIMP may be trying to use the command from your ). I have it in my systemPackages and I got past that stage. However, is still blocking the usage of some plugins.
Spent some time in and it looks like the extension mapping from file only searches in path, not in the mapping described on previous lines and registered in : : The extension is so some other mechanism than extension matching must be involved – perhaps shebangs are applied. We will still want to hardcode the path to ensure purity.
Change:
nix-bash-completions = callPackage ../shells/bash/nix-bash-completions { }; <ins> undistract-me = callPackage ../shells/bash/undistract-me { }; </ins> dash = callPackage ../shells/dash { }; dasht = callPackage ../tools/misc/dasht { };

Discussion:
Project description A bash utility; "Notifies you when long-running terminal commands complete." Metadata homepage URL: license: "All of undistract-me, including this file, is made available with the Expat license. See LICENSE for details."
Change:
, fetchzip , fetchFromGitHub , butler <del> , electron_11 </del> <ins> , electron </ins> , steam-run , makeWrapper , copyDesktopItems

Discussion:
Steps to reproduce the behavior: itch system: host os: multi-user?: sandbox: version: channels(root): channels(username): nixpkgs:
Looks like there is an issue already posted for this package NixOS/nixpkgs and there was a PR (NixOS/nixpkgs which uses a canary build instead) posted. Since there is no stable update (the canary builds uses a separate config directory, which is also explained here ) this is still a upstream issue.

I can't update my system when itch should be installed: error: Package ‘electron-11.5.0’ in /nix/store/5wja3wj4lq4gijjgg2lx3966pf6lzijc-nixos- is marked as insecure, refusing to evaluate. Steps to reproduce the behavior: in no error also reproducible on unstable i guess electron needs an update or use a later electron version, if possible system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
It's an upstream issue, trying to use a newer Electron version makes Itch straight up not work (it gets stuck at the initial loading). unfortunately seems to be abandoned. There technically is a new version (25.6.1-canary), but it hasn't been distributed as a binary on , and looking at the commits it doesn't change much. There is really nothing that can be done here. You can do this on your if you don't care about the security risks:
Upstream issue:
Change:
}: let <del> # Returns a true if the builder's rustc was built with support for the target. targetAlreadyIncluded = lib.elem stdenv.hostPlatform.rust.rustcTarget (lib.splitString "," (lib.removePrefix "--target=" ( lib.elemAt (lib.filter (f: lib.hasPrefix "--target=" f) pkgsBuildBuild.rustc.unwrapped.configureFlags) 0) )); # If the build's rustc was built with support for the target then reuse it. (Avoids uneeded compilation for targets like `wasm32-unknown-unknown`) rustc' = if targetAlreadyIncluded then pkgsBuildBuild.rustc else rustc; cargo' = if targetAlreadyIncluded then pkgsBuildBuild.cargo else cargo; </del> # Create rustc arguments to link against the given list of dependencies # and renames. #

Discussion:
I'm running an issue with overriding the rust toolchain since , I pass the following to crate2nix: to set the toolchain when building something, since I don't want to override the toolchain globally. But after this PR it doesn't work because it uses the toolchain in instead of the one I'm passing in. Now I don't really know how to override the rust toolchain to the version I want. is a nightly version I got from This problem is caused by this optimization: Another issue is that the attribute is missing in rust-overlay:
I'm having this issue as well. I've overridden my input to my flake to as a workaround for now.
Hi, sorry for the delay, I'm back home now from "holiday". Can any of you give me a minimal flake that reproduces the issue so I can experiment and find the best way to fix it?
I'm also hitting this. I don't have a minimal flake but I can at least offer the error message which seems to be missing from the OP.
Let me know if this fixes it.
unfortunately it does not, because it still defaults to for the rustc compiler. I've created a reproduction here: As you can see in I'm overriding rustc and cargo to the specific nightly version I want, but when I run I get the following output: This is the rustc version that's current in nixpkgs, not the nightly I specified. Thanks a lot for looking into this
One problem with your reproducer is that it uses the for which takes an arg called not . I think that still wouldn't have solved it. I made some changes in the PR that would allow passing a custom toolchain via the but also using . I did some refactoring to get rid of the and variables.
Change:
, vala , wrapGAppsHook , glib <ins> , glib-networking </ins> , gtk3 , json-glib , libappindicator

Discussion:
Gives this error: , yet installing doesn't fix the problem. Steps to reproduce the behavior: Meteo That the Maps section works. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
I have this exact issue. Hoping for some clarity.
should be here:
Change:
, wrapGAppsHook , sysprof , desktop-file-utils <ins> , libcap_ng </ins> }: stdenv.mkDerivation rec {

Discussion:
Capability wrappers are somewhat limited. They require the capability be part of the ambient set for it to survive execv's, ie. when the wrapper executes the source binary (). This means any program spawned from a wrapped binary will also inherit the capabilities. We really don't want programs launched from gnome-shell to inherit capsysnice obviously. In particular bubblewrap fails to work if it possess any extra caps, breaking at least flatpaks and epiphany. So as far as I can see we have two options: Actually copy to wrapperDir and set capsysnic=+ep. This should be pretty easy, but also quite ugly (see for context). Patch mutter to drop inheritable, we could probably adopt . This should probably work as the ambient set only propagates if inheritable is set. cc
Patching mutter to drop inheritable works :tada:, will make a PR :)
Does the rationale for not merging it not apply to us?
No it shouldn't. We only drop inheritable to prevent the ambient set being passed on, while keeping effective and permitted for gnome-shell. (it might be possible to drop the ambient set with , but I went with just clearing inheritable):
Change:
<ins> { lib , bundlerApp , bundlerUpdateScript }: bundlerApp rec { pname = "pru"; gemdir = ./.; exes = [ "pru" ]; meta = with lib; { homepage = "https://github.com/grosser/pru"; description = "Pipeable Ruby"; longDescription = '' pru allows to use Ruby scripts as filters, working as a convenient, higher-level replacement of typical text processing tools (like sed, awk, grep etc.). ''; license = licenses.mit; maintainers = with maintainers; [ AndersonTorres ]; }; passthru.updateScript = bundlerUpdateScript pname; } </ins>

Discussion:
Project description Pipeable Ruby - forget about grep / sed / awk / wc ... use pure, readable Ruby Metadata homepage URL: source URL: license: mit platforms: ruby
Looks like you got this in
Change:
digikam5 = throw "'digikam5' has been renamed to/replaced by 'digikam'"; # Converted to throw 2022-02-22 dirmngr = throw "dirmngr has been removed: merged into gnupg"; # Added 2022-05-13 disper = throw "disper has been removed: abandoned by upstream"; # Added 2022-03-18 <del> displaycal = throw "displaycal has been removed from nixpkgs, as it hasn't migrated to python3"; # Added 2022-01-12 </del> dmtx = throw "'dmtx' has been renamed to/replaced by 'dmtx-utils'"; # Converted to throw 2022-02-22 dnnl = oneDNN; # Added 2020-04-22 docbook5_xsl = throw "'docbook5_xsl' has been renamed to/replaced by 'docbook_xsl_ns'"; # Converted to throw 2022-02-22

Discussion:
Project description . A few months back the project was removed because Python 2 was removed, and the Pillow lib was insecure too. This project is a revival of the project but under Python 3. In fact they have stated: "Everything should be working now". DisplayCAL is a tool for many color-related tasks; from the docs: Calibration + Characterization (Profiling). Installing the created ICC profile both locally and system-wide (requires root permissions). Profile Info window is now fully working (on some systems we still have an issue related to default values ). Measurement report creation. Creating, displaying and uploading Colorimeter Corrections. Measuring and reporting display uniformity. Creating charts with Test Chart Editor and creating diagnostic 3d data. Creating 3D LUTs. Creating synthetic ICC profiles. Metadata homepage URL: source URL: license: GPL 3.0 platforms: unsure, but at least Linux
Change:
for i in * do cd $i <del> patch -d vboxvideo -p6 < ${./linux-4.14.patch} </del> find . -type f | xargs sed 's/depmod -a/true/' -i make cd ..

Discussion:
In a lot of cases, upstream sources or releases become unavailable (e.g. grsecurity) or even get modified (e.g. texlive) which breaks the package in older versions of nixpkgs. It would be nice to duplicate the sources via a torrent. This doesn't involve any trust, because the hash of the sources is known beforehand and would allow older nixpkgs to work as long as someone uses the desired package.
We've discussed a before but have mostly resisted because unless we build deep support for it into a persistent Nix daemon, as we could implement today would be a terrible "torrent citizen", and would never seed. Probably more promising is to build support for IPFS into Nix itself. See discussion at and Either way, I don't think most of the work would happen inside nixpkgs, so if you think the above issues don't cover what you want, I'd suggest posting more information on the Nix issue tracker rather than in here.
FWIW I had an experimental via but dropped it because of the same reasons -- it'd be an awful "torrent citizen".
Actually, the ipfs issue seems to be exactly what I wanted, so I'll close this issue.
can you share your please? I'm currently thinking about packaging the program where using aria2c for install is an official way to install
moved to PR <detailspkgs/build-
Change:
githubId = 43088426; name = "Mihnea Stoian"; }; <ins> mikaelfangel = { email = "nixpkgs.bottle597@passfwd.com"; github = "MikaelFangel"; githubId = 34864484; name = "Mikael Fangel"; }; </ins> mikefaille = { email = "michael@faille.io"; github = "mikefaille";

Discussion:
Project description slurm started as a FreeBSD port of the Linux ppp link monitor called pppstatus by Gabriel Montenegro. Hendrik Scholz ripped off the ppp dependent parts and the email checks to turn in into a generic network load monitor for BSD, Linux, HP-UX and Solaris. Metadata homepage URL: source URL: license: gpl2 platforms: unix, linux
Change:
}: buildPythonPackage rec { <del> version = "1.6.0"; </del> <ins> version = "1.6.1"; </ins> pname = "strictyaml"; disabled = isPy27; src = fetchPypi { inherit pname version; <del> sha256 = "73fa9769214a310486d7916453a09bd38b07d28a9dcbdf27719183c1d7d949f6"; </del> <ins> sha256 = "688be16ee5d1a2f94aa4abdc6d881e8e254d173d724ac88725955fe66bdb63d4"; </ins> }; postPatch = ''

Discussion:
Upgrading fails, seemingly because the existing systemd version is newer in 21.11 than unstable. Steps to reproduce the behavior: NixOS 21.11 21.11 channel, add unstable channel NixOS upgrades from 21.11 to unstable. is the commit upgrading systemd to 249.7, cherry picks it to 21.11. Adding the flag to the invocation would also solve this issue, albeit leaving the newer EFI files in place. <!-- 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.
I think the corresponding PR is
As pointed out above by this will be fixed when staging-next gets merged ().
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
Change:
freetype qtbase qtscript lame zlib libGLU libGL perl libsamplerate libbluray lzo alsa-lib libpulseaudio fftwSinglePrec libX11 libXv libXrandr libXvMC libXmu libXinerama libXxf86vm libXmu libuuid taglib exiv2 soundtouch libzip <ins> libhdhomerun </ins> ] ++ lib.optional withWebKit qtwebkit; nativeBuildInputs = [ pkg-config which yasm libtool autoconf automake file ];

Discussion:
MythTV was not compiled with HDHOMERUN support. To reproduce, start the server configured for an hdhomerun tuner. See this error in the systemd journal: This issue just requires adding to the . I have recompiled and tested with the libhdhomerun library, and it fixes the issue. I'll create a PR with the change, hopefully someone can pull it, is listed as the maintainer.
fyi... You'll most likely need to add the workaround from to actually get your tuner to detect: