jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug After the PR is merged, as , fails to evaluate on . This is quite annoying because is a dependency of , which makes a sizable chunk of fail to evaluate on . I encountered this issue when trying to build . To Reproduce Steps to reproduce the behavior: Expected behavior , therefore to evaluate and run successfully on . cc
I believe should change the error message, but not fix the problem. Now the trace should go like hidapi -systemd, instead of hidapi -libusb -systemd. I don't really know where the infinite recursion comes from as that doesn't happen with nixos-19.09, however even if that didn't happen it wouldn't matter because systemd doesn't work with musl. If you want to fix this you'd have to look into getting the systemd dependency out of the hidapi nix expression. I'm not really sure why it's there in the first place, glancing at the hidapi , it seems like it depends on udev, which depends on util-linux which depends on systemd, but not on systemd directly and util-linux can be build without systemd. The utillinux nix expression already accounts for that possibility, you'd just have to make it actually do that for pkgsMusl. You could take the libusb nix expression as a template on how to achieve this. Disclaimer: I have virtually no experience with these low-level things, so I may be wrong.

Discussion:
, withGssapiPatches ? false , kerberos , libfido2 <del> , withFIDO ? stdenv.hostPlatform.isUnix </del> <ins> , withFIDO ? stdenv.hostPlatform.isUnix && !stdenv.hostPlatform.isMusl </ins> , linkOpenssl? true }:
Change:
Describe the bug See e.g. To Reproduce Running the build locally reproduces it, though I can't see any relation with the reported Nix version on my system. Speculation: some dependency of the cachix build might have "cached" version of the nix daemon running on its builder (and succeeded)? Maintainers will probably know much quicker than me. Notify maintainers
A slight clarification: This appears to just be a test at parsing various Nix versions, not that Nix is installed on whatever machine ran the build/test. This was discussed on livestream last Friday, where he filed this issue: (Here's the part of the stream where it occurred: )

Discussion:
then super.conduit-extra.overrideAttrs (drv: { __darwinAllowLocalNetworking = true; }) else super.conduit-extra; <ins> # https://github.com/cachix/cachix/issues/308 cachix = dontCheck super.cachix; </ins> # Fix Darwin build. halive = if pkgs.stdenv.isDarwin then addBuildDepend super.halive pkgs.darwin.apple_sdk.frameworks.AppKit
Change:
Project description Screenkey is currently in version 0.9. The latest version is currently 1.1. Major changes: The repository was migrated from github to gitlab Version 1.0 switched to Python 3 and GTK 3 Metadata homepage URL: source URL: changelog URL: Nix source URL:

Discussion:
{ lib <del> , substituteAll , buildPythonApplication , fetchFromGitHub , distutils_extra , setuptools-git </del> <ins> , fetchFromGitLab # native </ins> , intltool <del> , pygtk , libX11 , libXtst </del> , wrapGAppsHook <del> , gnome3 </del> <ins> , file # not native , xorg , gobject-introspection , gtk3 , python3 </ins> }: <del> buildPythonApplication rec { </del> <ins> python3.pkgs.buildPythonApplication rec { </ins> pname = "screenkey"; <del> version = "0.9"; </del> <ins> version = "1.2"; </ins> <del> src = fetchFromGitHub { owner = "wavexx"; </del> <ins> src = fetchFromGitLab { owner = "screenkey"; </ins> repo = "screenkey"; <del> rev = "screenkey-${version}"; sha256 = "14g7fiv9n7m03djwz1pp5034pffi87ssvss9bc1q8vq0ksn23vrw"; </del> <ins> rev = "v${version}"; sha256 = "1x13n57iy2pg3h3r994q3g5nbmh2gwk3qidmmcv0g7qa89n2gwbj"; </ins> }; <del> patches = [ (substituteAll { src = ./paths.patch; inherit libX11 libXtst; }) ]; </del> nativeBuildInputs = [ <del> distutils_extra setuptools-git </del> <ins> python3.pkgs.distutils_extra # Shouldn't be needed once https://gitlab.com/screenkey/screenkey/-/issues/122 is fixed. </ins> intltool <ins> # We are not sure why is this needed, but without it we get "file: command # not found" errors during build. file </ins> wrapGAppsHook <ins> # for setup hook gobject-introspection </ins> ]; buildInputs = [ <del> gnome3.adwaita-icon-theme </del> <ins> gtk3 </ins> ]; <del> propagatedBuildInputs = [ pygtk </del> <ins> propagatedBuildInputs = with python3.pkgs; [ pycairo pygobject3 </ins> ]; <ins> # Prevent double wrapping because of wrapGAppsHook dontWrapGApps = true; # https://github.com/NixOS/nixpkgs/issues/56943 strictDeps = false; preFixup = '' makeWrapperArgs+=("''${gappsWrapperArgs[@]}") ''; </ins> # screenkey does not have any tests doCheck = false; <ins> # Fix CDLL python calls for non absolute paths of xorg libraries postPatch = '' substituteInPlace Screenkey/xlib.py  --replace libX11.so.6 ${lib.getLib xorg.libX11}/lib/libX11.so.6  --replace libXtst.so.6 ${lib.getLib xorg.libXtst}/lib/libXtst.so.6 ''; </ins> meta = with lib; { homepage = "https://www.thregr.org/~wavexx/software/screenkey/"; description = "A screencast tool to display your keys inspired by Screenflick";

<del> --- a/Screenkey/xlib.py +++ b/Screenkey/xlib.py @@ -6,7 +6,7 @@ from ctypes import * ## base X11 -libX11 = CDLL('libX11.so.6') +libX11 = CDLL('@libX11@/lib/libX11.so.6') # types Atom = c_ulong @@ -278,7 +278,7 @@ ## record extensions -libXtst = CDLL('libXtst.so.6') +libXtst = CDLL('@libXtst@/lib/libXtst.so.6') # types XPointer = String </del>  No newline at end of file

quazip = quazip_qt4; }; <del> screenkey = python2Packages.callPackage ../applications/video/screenkey { }; </del> <ins> screenkey = callPackage ../applications/video/screenkey { }; </ins> quazip_qt4 = libsForQt5.quazip.override { qtbase = qt4;
Change:
Describe the bug I'm hunting down packages that reference gcc. One of them is (maintainers: & ). Here's why: The fault is the fact that the build flag doesn't remove all references, as one might expect (EDIT, see: ). I'm up to including this feature, but I was wondering perhaps it'd be legit to disable this feature for the derivation? I opened a PR at (EDIT).
But that would mean gems that require a compiler would no longer work.
The suggestion is for , not . Isn't the derivation that's used to build the gems? According to:
It still has support for gems, so some will fail with gcc. What exactly is the use case for ?
Technically it's not used anywhere, according to .
I'd like to make my - with an overlay. The goal is to make the 1 or 2 pure ruby scripts I have on my system not pull , as they do today.
But what is the reason? You're likely to have a version of ruby that includes gcc on your system anyway, so you don't really save any space. And the use-case would be plain ruby scripts with only the gems that don't require system libraries. We have no users in nixpkgs of presumably because it's rather pointless. And while of course we can strip gcc from rubyMinimal (there's no harm), I'd rather say drop instead.
Not If I'll apply and this overlay: This allows me to not need GCC for for example - which is the only ruby gem I use. For example, run with this PR and that overlay applied: And you should get: And without , (and without the overlay because it would fail) you should get: is the only derivation that needs ruby that I actually use. I've updated the 1st comment in to exemplify this overlay as a possible usecase. Well I tend to agree - even for asciidoctor which should be pretty much a pure ruby gem, it still required and which aren't enabled in current . Hence I tend to agree. OK so I've updated to include a drop to , including release notes and an alias. Waiting for your review :crossed_fingers: .
This issue has been mentioned on NixOS Discourse. There might be relevant details there:

Discussion:
, fetchurl, fetchpatch, fetchFromSavannah, fetchFromGitHub , useRailsExpress ? true , rubygemsSupport ? true <ins> , JitSupport ? true </ins> , zlib, zlibSupport ? true , openssl, opensslSupport ? true , gdbm, gdbmSupport ? true

configureFlags = ["--enable-shared" "--enable-pthread" "--with-soname=ruby_${tag}"] ++ op useRailsExpress "--with-baseruby=${baseruby}/bin/ruby" <ins> ++ op (!JitSupport) "--disable-jit-support" </ins> ++ op (!docSupport) "--disable-install-doc" ++ ops stdenv.isDarwin [ # on darwin, we have /usr/include/tk.h -- so the configure script detects

${removeReferencesTo}/bin/remove-references-to  -t ${stdenv.cc}  $out/lib/libruby* <ins> ${removeReferencesTo}/bin/remove-references-to  -t ${stdenv.cc}  $out/${passthru.libPath}/${stdenv.targetPlatform.system}/rbconfig.rb </ins> '' } # Bundler tries to create this directory

rubyMinimal = ruby.override { # gem support is minimal overhead rubygemsSupport = true; <ins> removeReferenceToCC = true; JitSupport = false; </ins> useRailsExpress = false; zlibSupport = false; opensslSupport = false;
Change:
Describe the bug Current version 0.9.73 is broken (download link at least). To Reproduce Steps to reproduce the behaviour: -env -i typora ... ... Expected behaviour Typora installed successfully. Screenshots ! Additional context Maybe we should replace the deb package: ${version} by Notify maintainers Metadata /nix/store/5k0id2x2sqj9k7kb9f1jzf382mpn6b2r-nix-info copying path '/nix/store/5k0id2x2sqj9k7kb9f1jzf382mpn6b2r-nix-info' from ''... system: host os: multi-user?: sandbox: version: channels(root): channels(vutaliy): nixpkgs:
The version referenced is simply outdated and not available any more from upstream. Switching to the is no solution, as the contents may change without being visible through the file name, leading to a hash mismatch and breaking the build.
I tried updating to 0.9.89 with sha256 but the .deb has setuid for the chrome sandbox and with it builds, but crashes at startup.

Discussion:
, lib , fetchurl , makeWrapper <del> , electron_5 </del> <ins> , electron_8 </ins> , dpkg , gtk3 , glib

stdenv.mkDerivation rec { pname = "typora"; <del> version = "0.9.73"; </del> <ins> version = "0.9.89"; </ins> src = fetchurl { url = "https://www.typora.io/linux/typora_${version}_amd64.deb"; <del> sha256 = "1fgcb4bx5pw8ah5j30d38gw7qi1cmqarfhvgdns9f2n0d57bvvw3"; </del> <ins> sha256 = "0gk8j13z1ymad34zzcy4vqwyjgd5khgyw5xjj9rbzm5v537kqmx6"; </ins> }; nativeBuildInputs = [

gtk3 ]; <del> unpackPhase = "dpkg-deb -x $src ."; </del> <ins> # The deb contains setuid permission on `chrome-sandbox`, which will actually not get installed. unpackPhase = "dpkg-deb --fsys-tarfile $src | tar -x --no-same-permissions --no-same-owner"; </ins> dontWrapGApps = true;

''; postFixup = '' <del> makeWrapper ${electron_5}/bin/electron $out/bin/typora  </del> <ins> makeWrapper ${electron_8}/bin/electron $out/bin/typora  </ins> --add-flags $out/share/typora  "''${gappsWrapperArgs[@]}"  ${lib.optionalString withPandoc ''--prefix PATH : "${lib.makeBinPath [ pandoc ]}"''}
Change:
Describe the bug A clear and concise description of what the bug is. the vscode-extensions directory has the structure so should be called with the argument instead of To Reproduce Steps to reproduce the behavior: ... ... ... Expected behavior A clear and concise description of what you expected to happen. 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. Maintainer information:

Discussion:
ln -sT "${vscode}/share/applications/${executableName}.desktop" "$out/share/applications/${executableName}.desktop" ln -sT "${vscode}/share/applications/${executableName}-url-handler.desktop" "$out/share/applications/${executableName}-url-handler.desktop" makeWrapper "${vscode}/bin/${executableName}" "$out/bin/${executableName}" ${lib.optionalString (vscodeExtensions != []) '' <del> --add-flags "--extensions-dir ${combinedExtensionsDrv}" </del> <ins> --add-flags "--extensions-dir ${combinedExtensionsDrv}/share/vscode/extensions" </ins> ''} ''

{ stdenv, lib, buildEnv, writeShellScriptBin, fetchurl, vscode, unzip, jq }: let <del> extendedPkgVersion = lib.getVersion vscode; extendedPkgName = lib.removeSuffix "-${extendedPkgVersion}" vscode.name; </del> buildVscodeExtension = a@{ name, <del> namePrefix ? "${extendedPkgName}-extension-", </del> src, # Same as "Unique Identifier" on the extension's web page. # For the moment, only serve as unique extension dir.

buildInputs ? [], ... }: <del> stdenv.mkDerivation ((removeAttrs a [ "vscodeExtUniqueId" ]) //  { </del> <ins> stdenv.mkDerivation ((removeAttrs a [ "vscodeExtUniqueId" ]) // { </ins> <del> name = namePrefix + name; </del> <ins> name = "vscode-extension-${name}"; </ins> inherit vscodeExtUniqueId; inherit configurePhase buildPhase dontPatchELF dontStrip; <del> installPrefix = "share/${extendedPkgName}/extensions/${vscodeExtUniqueId}"; </del> <ins> installPrefix = "share/vscode/extensions/${vscodeExtUniqueId}"; </ins> buildInputs = [ unzip ] ++ buildInputs;

vscodeDefault = vscode; }; vscodeExts2nix = import ./vscodeExts2nix.nix { inherit lib writeShellScriptBin; vscodeDefault = vscode;

inherit lib buildEnv writeShellScriptBin extensionsFromVscodeMarketplace jq; vscodeDefault = vscode; }; <del> in </del> <ins> in </ins> { inherit fetchVsixFromVscodeMarketplace buildVscodeExtension buildVscodeMarketplaceExtension extensionFromVscodeMarketplace
Change:
the drop patches were upstreamed to libjpeg in version 9d 2020-01-12: https://abi- and are no longer maintained so the separate package can be safely removed.
will fix this
thx.

Discussion:
<del> { stdenv, fetchurl, static ? true }: with stdenv.lib; stdenv.mkDerivation { name = "libjpeg-drop-9b"; srcs = [ (fetchurl { url = "http://www.ijg.org/files/jpegsrc.v9b.tar.gz"; sha256 = "0lnhpahgdwlrkd41lx6cr90r199f8mc6ydlh7jznj5klvacd63r4"; }) (fetchurl { url = "http://jpegclub.org/droppatch.v9b.tar.gz"; sha256 = "022bnvpird7w5pwbfqpq7j7pwja5kp6x9k3sdypcy3g2nwwy2wwk"; }) ]; postUnpack = '' rm jpegtran mv jpegtran.c jpeg-9b/jpegtran.c mv transupp.c jpeg-9b/transupp.c mv transupp.h jpeg-9b/transupp.h ''; configureFlags = [] ++ optionals static [ "--enable-static" "--disable-shared" ]; outputs = [ "bin" "dev" "out" "man" ]; meta = { homepage = "http://jpegclub.org/jpegtran/"; description = "Experimental lossless crop 'n' drop (cut & paste) patches for libjpeg"; license = stdenv.lib.licenses.free; }; } </del>

libgumbo = gumbo; # added 2018-01-21 libGL_driver = mesa.drivers; libintlOrEmpty = stdenv.lib.optional (!stdenv.isLinux || stdenv.hostPlatform.libc != "glibc") gettext; # added 2018-03-14 <ins> libjpeg_drop = libjpeg_original; # added 2020-06-05 </ins> libjson_rpc_cpp = libjson-rpc-cpp; # added 2017-02-28 liblapackWithoutAtlas = lapack-reference; # added 2018-11-05 liblrdf = lrdf; # added 2018-04-25

libjpeg_original = callPackage ../development/libraries/libjpeg { }; # also known as libturbojpeg libjpeg_turbo = callPackage ../development/libraries/libjpeg-turbo { }; <del> libjpeg_drop = callPackage ../development/libraries/libjpeg-drop { }; </del> libjpeg = libjpeg_turbo; libjreen = callPackage ../development/libraries/libjreen { };
Change:
has a broken hash (did upstream replace sources, or did we fail to update hashes while bumping?): fails to build, as isn't found in the sources (did we bump without checking it built)? I get the same has mismatch for on release-20.03, btw: seems to build on release-20.03, at least it doesn't fail with the same error as on master, and is already running for some minutes ;-)
Strange, that shouldn't happen as the hashes are automatically generated by . The only known issue is that sometimes the tarball is not yet uploaded when we run the script in which case the hash won't get updated (but this wasn't the case as the hash did get updated in ). So I guess upstream must have changed the sources... Yes, we always bump both chromiumBeta and chromiumDev without checking if they still build (due to lack of resources and to not delay stable security updates - both are not build by Hydra anyway). We use them to fix build errors before they propagate to the stable channel and usually chromiumBeta should always build (but there are sometimes bigger changes in the beta channel that break a working build). As for chromiumDev: Since the last commit updated the dev channel from M84 to M85 this is not surprising. I already started a build yesterday to check what happens.
I tried to understand to see what URL is pointing to , but failed. I opened , but for now I can't fix that hash to unbreak .
(also regarding ): AFAIK isn't even required anymore. Anyway, I reverted the last update (required so that the script recomputes the hash) and re-run and it did generate the same hash as before. I quickly tried to locate the source (I thought this was from the CSV file, but apparently not - seems like it's coming from the Debian mirror?) but I didn't find it anymore. IIRC there are also a few Nixpkgs issues regarding . Edit: It's the hash of the content of the URL produced by , e.g.: Edit2: Oh, and of course it's still needed then ( source hash), but I though some issue mentioned that we don't need it anymore?

Discussion:
# This file is autogenerated from update.sh in the same directory. { beta = { <del> sha256 = "1g052h8g458qx04wbkz93j7hciw12b2b3w93x2849ag69q6g4qa9"; sha256bin64 = "0lkjl09vnj2bd1jry3awbg4z34vjnzd88p73a6x7pyrfq079l6vb"; version = "83.0.4103.61"; </del> <ins> sha256 = "1di0fhhv6lljc2b50i0i8qx5y5xswgxz1bimpda790sb3b1xsdzx"; sha256bin64 = "1f5qwx4476l4fvbw9w2i22i080bahlf83dzzpnbny7hk831g7msw"; version = "84.0.4147.38"; </ins> }; dev = { <del> sha256 = "0f7m57acv79yzq3yg2xkchqqwisdgjv8h5xngp2i2v2md9jkfkbq"; sha256bin64 = "0b0w0nwa64gf99d617idjjgrjym3qc6p9h41kn5r9j2x46lxzply"; version = "84.0.4143.2"; </del> <ins> sha256 = "04jbh8bsvqkm8mdsgyv0465fq5lhz0nn0mcs07kj5hnmzx1g2f3a"; sha256bin64 = "0d9knpqbps06wgfgp2s7z693dqiip0m771mv3j2856h5v9rv210l"; version = "85.0.4158.4"; </ins> }; stable = { <del> sha256 = "1g052h8g458qx04wbkz93j7hciw12b2b3w93x2849ag69q6g4qa9"; sha256bin64 = "1wji1ak6gi2a7lynxwvgpqsaz7zma9h2b9qbb5x3gzbv2dj37fmd"; version = "83.0.4103.61"; </del> <ins> sha256 = "10vg0fmwlkzpnixhhhcwccxshqdfq7rh0ribij7wgkw42bv0bi0j"; sha256bin64 = "09vz7ygixs7lwlsvbby3dmc2gz0vpjwalzdh6l6apc4dngyr095k"; version = "83.0.4103.97"; </ins> }; }
Change:
Describe the bug When I try to preview videos like .mp4 or webm in Nautilus using Sushi, it says "Your GStreamer installation is missing a plug-in". To Reproduce Steps to reproduce the behavior: NixOS with Gnome3 desktop space on a video file in Nautilus Additional context It's possible that there's some configuration in my homedir that makes it break, since I have the same homedir that I had under other Linux installs, not sure how to find it however. outputs Notify maintainers maybe? Metadata Please run and paste the result. system: host os: multi-user?: sandbox: version: channels(wmertens): channels(root): nixpkgs: Maintainer information:
Would need to add here, I think.
that makes sense - it seems like I would like the bad and the ugly too. How about a nixpkgs configuration setting that decides which plugin sets to load, and having plugins-base include them? That should make it backwards-compatible.
Most of them depend on base so that would be a dependency cycle. Also we would need to move the wrappers into a separate derivation or we would have to rebuild everything. Alternately, you can set environment variable (I believe some NixOS module does that). Not a fan but it should work provided some ABI break does not sneak in.
I marked this as stale due to inactivity. &rarr;
Still a problem
I marked this as stale due to inactivity. &rarr;
if sushi is not a dependent of any package then why would we have to rebuild everything? What do you mean by everything? Perhaps until a separate wrapper derivation is composed we can add a configuration option to the nixos module that would add these gstreamer to it if needed. Also, doesn't work at all for me nowadays, I think since Gnome 41.
I was replying to Wout’s question above regarding a general solution pulling extra plug-ins into gst-plugins-base. For now, I would be fine with adding everything unconditionally to sushi as mentioned in I must have forgotten to test it during the update when I removed libmusicbrainz but forgot to add libsoup: Could you try

Discussion:
, gnome , gtksourceview4 , gjs <del> , webkitgtk_4_1 </del> <ins> , libsoup , webkitgtk </ins> , icu , wrapGAppsHook , gst_all_1

gtksourceview4 gdk-pixbuf librsvg <del> webkitgtk_4_1 </del> <ins> libsoup webkitgtk </ins> libepoxy gst_all_1.gstreamer gst_all_1.gst-plugins-base gst_all_1.gst-plugins-good <ins> gst_all_1.gst-plugins-bad gst_all_1.gst-plugins-ugly </ins> ]; # See https://github.com/NixOS/nixpkgs/issues/31168
Change:
Describe the bug Package stopped building, not sure when. Getting To Reproduce Steps to reproduce the behavior: on unstable Expected behavior The package builds 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.

Discussion:
--replace 'pygments==2.1.3' 'pygments>=2.1,<3.0'  --replace 'pyopenssl==19.0.0' 'pyopenssl'  --replace 'python-dateutil==2.8.0' 'python-dateutil==2.8.*'  <del> --replace 'pyyaml==5.1' 'pyyaml' </del> <ins> --replace 'pyyaml==5.1' 'pyyaml'  --replace 'requests[socks]==2.22.0' 'requests[socks]' </ins> substituteInPlace requirements-dev.txt  --replace 'plone.testing==5.0.0' 'plone.testing'  --replace 'pep8==1.7.0' 'pep8==1.7.*'
Change:
Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: This is a bit annoying, as --.
Uhm, It looks like it's also a problem for i3 users. I'm not a perl programmer so I don't think I can do much to fix the package. For rxvt-unicode, you can temporarily remove bidi from your plugins, see the .
Looks like some tests are failing for . Temporary workaround is to turn off tests for the package.
It is expecting in , but doesn't seem to provide it, so I have no idea what should provide it...
Bisecting showed this to be broken by : can you take a look?
Looking

Discussion:
for each package in a separate file: the call to the function would be almost as much code as the function itself. */ <del> {config, pkgs, fetchurl, fetchpatch, fetchFromGitHub, stdenv, perl, overrides, buildPerl, shortenPerlShebang}: </del> <ins> { config , stdenv, buildPackages, pkgs , fetchurl, fetchpatch, fetchFromGitHub , perl, overrides, buildPerl, shortenPerlShebang }: </ins> # cpan2nix assumes that perl-packages.nix will be used only with perl 5.28.2 or above assert stdenv.lib.versionAtLeast perl.version "5.28.2";

url = "mirror://cpan/authors/id/X/XA/XAOC/ExtUtils-PkgConfig-1.16.tar.gz"; sha256 = "bbeaced995d7d8d10cfc51a3a5a66da41ceb2bc04fedcab50e10e6300e801c6e"; }; <ins> nativeBuildInputs = [ buildPackages.pkgconfig ]; </ins> propagatedBuildInputs = [ pkgs.pkgconfig ]; meta = { homepage = "http://gtk2-perl.sourceforge.net";