jiebi/CodeConvo huggingface dataset:
Change:
On the master branch ethminer fails to compile with messages about missing getglobalepochcontext from ethash namespace. Attempt to build ethminer on master branch. Successful compilation. Root of the failure is in changes done to the structure of the dependency chfast/ethash; specifically, 0.6.0 -0.7.0. Patching the libethcore/EthashAux.h file in the ethminer repo, by adding to the headers, and the file by changing the line to does the job.

Discussion:
<ins> diff --git a/libethcore/CMakeLists.txt b/libethcore/CMakeLists.txt index 1a53de8..832e926 100644 --- a/libethcore/CMakeLists.txt +++ b/libethcore/CMakeLists.txt @@ -7,7 +7,7 @@ set(SOURCES include_directories(BEFORE ..) add_library(ethcore ${SOURCES}) -target_link_libraries(ethcore PUBLIC devcore ethash::ethash PRIVATE hwmon) +target_link_libraries(ethcore PUBLIC devcore ethash::ethash ethash-global-context PRIVATE hwmon) if(ETHASHCL) target_link_libraries(ethcore PRIVATE ethash-cl) diff --git a/libethcore/EthashAux.h b/libethcore/EthashAux.h index d9aadc7..fe5c6cf 100644 --- a/libethcore/EthashAux.h +++ b/libethcore/EthashAux.h @@ -22,6 +22,7 @@ #include <libdevcore/Worker.h> #include <ethash/ethash.hpp> +#include <ethash/global_context.hpp> namespace dev { </ins>

cudatoolkit ]; <ins> patches = [ # global context library is separated from libethash ./add-global-context.patch ]; </ins> preConfigure = '' sed -i 's/_lib_static//' libpoolprotocols/CMakeLists.txt '';
Change:
I am running Brave with with ozone/wayland (see for how to achieve that). Brave 1.26.77 was fine, while 1.27.111 crashes with Steps to reproduce the behavior: Brave with Wayland () 1.27.111 to run Should start as Wayland client (I always check with ) I checked the underlying .deb package we are using. The only change in dependencies I could find was . Replacing our with did not fix it. Here is the output where I observed that: Please run and paste the result.
r-ryantm is a bot. Ping the real maintainers
Thanks for the notice. pinging
I can reproduce this on 1.30.89:
Still happens:
with applied fails with
I can confirm that fixes this.

Discussion:
, pango , pipewire , udev <ins> , wayland </ins> , xorg , zlib , xdg-utils

pango pipewire udev <ins> wayland </ins> xdg-utils xorg.libxcb zlib

preFixup = '' # Add command line args to wrapGApp. gappsWrapperArgs+=(--add-flags ${lib.escapeShellArg commandLineArgs}) <ins> gappsWrapperArgs+=(--add-flags "''${NIXOS_OZONE_WL:+''${WAYLAND_DISPLAY:+--ozone-platform=wayland}}") </ins> ''; installCheckPhase = ''
Change:
I'm not at all familiar with catdoc, but I was building a bunch of random stuff (on macOS) to test some tooling I'm working on and it coincidentally broke because the catdoc output in my store is empty. I took a peek at hydra and it confirms that it produces output on Linux, but not on macOS: The only packages I see that consume catdoc are and , so they may both be subtly broken on macOS? catdoc doesn't have a listed maintainer, so I'm mentioning maintainers of catdocx and recoll in case they have a sense of whether it should work and just needs a fix, or should maybe get marked broken? recoll: catdocx:

Discussion:
}) ]; <ins> # Remove INSTALL file to avoid `make` misinterpreting it as an up-to-date # target on case-insensitive filesystems e.g. Darwin preInstall = '' rm -v INSTALL ''; </ins> configureFlags = [ "--disable-wordview" ]; meta = with lib; {
Change:
Cannot view any content when running the program because it complains about missing binaries. Steps to reproduce the behavior: to watch any stream No errors, stream works system: host os: multi-user?: sandbox: version: channels(admin): nixpkgs: Add and as runtime dependencies because the following works for me:

Discussion:
let basename = "streamlink-twitch-gui"; runtimeLibs = lib.makeLibraryPath [ libudev0-shim ]; <ins> runtimeBins = lib.makeBinPath [ streamlink ]; </ins> arch = if stdenv.hostPlatform.system == "x86_64-linux" then

dontConfigure = true; installPhase = '' <ins> runHook preInstall </ins> mkdir -p $out/{bin,opt/${basename},share} # Install all files, remove unnecessary ones cp -a . $out/opt/${basename}/ rm -r $out/opt/${basename}/{{add,remove}-menuitem.sh,credits.html,icons/} <del> wrapProgram $out/opt/${basename}/${basename} --add-flags "--no-version-check" --prefix LD_LIBRARY_PATH : ${runtimeLibs} </del> ln -s "$out/opt/${basename}/${basename}" $out/bin/ <del> ln -s "${desktopItem}/share/applications" $out/share/ </del> <ins> cp -r "${desktopItem}/share/applications" $out/share/ runHook postInstall ''; preFixup = '' gappsWrapperArgs+=( --add-flags "--no-version-check"  --prefix LD_LIBRARY_PATH : ${runtimeLibs}  --prefix PATH : ${runtimeBins} ) </ins> ''; desktopItem = makeDesktopItem {

description = "Twitch.tv browser for Streamlink"; longDescription = "Browse Twitch.tv and watch streams in your videoplayer of choice"; homepage = "https://streamlink.github.io/streamlink-twitch-gui/"; <del> downloadPage = https://github.com/streamlink/streamlink-twitch-gui/releases; </del> <ins> downloadPage = "https://github.com/streamlink/streamlink-twitch-gui/releases"; </ins> license = licenses.mit; maintainers = with maintainers; [ rileyinman ]; platforms = [ "x86_64-linux" "i686-linux" ];
Change:
On latest unstable, The new version of the skopeo package (1.4.0, introduced in ) seems to have changed something and now complains about as used . Build this docker package definition: on latest nixos-unstable (and nixpkgs-unstable) with skopeo 1.4.0, and you get the following error: Weirdly enough other definitions with actual SHA256 values (e.g. some definitions emitted from nix-prefetch-docker) do work, whereas others fail with the same message as above. Should not emit that skopeo error n/a n/a Please run and paste the result. Maintainer information:
Update: I think I have found out what reproduces this issue - not having downloaded the image in your store and in your docker. I'd used to get the SHAs and image tags & whatnot to test with, which warmed the cache and prevented the code path that triggers that error from getting hit. I think this may just be it, then: Invoking this version of skopeo with the options in dockerTools will raise the error above.
The work-around is also pretty clear: On the system where you are building the image, use and fetch all the base images that you're using. This works because nix-prefetch-docker seems to be based on skopeo 1.3 for me for now... It probably be won't soon, though. /:

Discussion:
destNameTag = "${finalImageName}:${finalImageTag}"; } '' skopeo  <del> --src-tls-verify=${lib.boolToString tlsVerify}  </del> --insecure-policy  --tmpdir=$TMPDIR  --override-os ${os}  --override-arch ${arch}  <del> copy "$sourceURL" "docker-archive://$out:$destNameTag"  </del> <ins> copy  --src-tls-verify=${lib.boolToString tlsVerify}  "$sourceURL" "docker-archive://$out:$destNameTag"  </ins> | cat  # pipe through cat to force-disable progress bar '';
Change:
On the latest 15.09, running this: Doesn't work because of kde-l10n-ca- No mirrors work. Tried it several times over different days, I think the source urls might need to be updated.
Apparently they removed 15.04.3 from their official mirrors, not just moved like dealt with in , as I can't find the files in :-/
Some of the tarballs are on but not all of them.
Oh, I've made a typo and missed the moved files.
Fixed.
Awesome. By the way, how did you fix it? The diff can't be shown on Github.
I just replaced the URLs.

Discussion:
{stdenv, fetchurl}: stdenv.mkDerivation rec { <del> name = "ncompress-4.2.4.3"; </del> <ins> name = "ncompress-4.2.4.4"; </ins> builder = ./builder.sh;

src = fetchurl { url = "mirror://sourceforge/project/ncompress/${name}.tar.gz"; <del> sha256 = "1y44ixc1w2vfvj1lm4dkcljlwv882ynrvm5i6l0lg1gf883j246l"; </del> <ins> sha256 = "0yjiwv1hwb253x3m6r1dq2k7m5c9nz0ib2j7fnm3hark7y6s42xh"; </ins> }; meta = {
Change:
Project description Used for client-side decorations on Wayland. Needed for adding libdecor support in . Metadata source URL: license: mit platforms: linux
I have this packaged in my user repository

Discussion:
<ins> { stdenv , lib , fetchFromGitLab , pkg-config , meson , ninja , wayland , wayland-protocols , cairo , dbus , pango , libxkbcommon }: stdenv.mkDerivation rec { pname = "libdecor"; version = "0.1.0"; src = fetchFromGitLab { domain = "gitlab.gnome.org"; owner = "jadahl"; repo = "libdecor"; rev = "${version}"; hash = "sha256:0qdg3r7k086wzszr969s0ljlqdvfqm31zpl8p5h397bw076zr6p2"; }; nativeBuildInputs = [ meson ninja pkg-config ]; buildInputs = [ wayland wayland-protocols cairo dbus pango libxkbcommon ]; meta = with lib; { homepage = "https://gitlab.gnome.org/jadahl/libdecor"; description = "Client-side decorations library for Wayland clients"; license = licenses.mit; platforms = platforms.linux; maintainers = with maintainers; [ artturin ]; }; } </ins>

libGL = null; }; <ins> libdecor = callPackage ../development/libraries/libdecor { }; </ins> libdigidoc = callPackage ../development/libraries/libdigidoc { inherit (darwin.apple_sdk.frameworks) Security; };
Change:
Having installed the current binaries on OS X, I get an error upon executing . It seems that on installation of , the binary somehow incorrectly got linked using a colon separated list containing both and : when it should actually be only the path to :
It seems the guys at macports have stumbled upon this issue three years ago: Let's see if their patch fixes it.

Discussion:
<del> { callPackage, fetchurl, tcl, ... } @ args: </del> <ins> { callPackage, fetchurl, tcl, stdenv, ... } @ args: </ins> callPackage ./generic.nix (args // rec {

sha256 = "1h96vp15zl5xz0d4qp6wjyrchqmrmdm3q5k22wkw9jaxbvw9vy88"; }; <del> patches = [ ./different-prefix-with-tcl.patch ]; </del> <ins> patches = [ ./different-prefix-with-tcl.patch ] ++ stdenv.lib.optionals stdenv.isDarwin [ ./Fix-bad-install_name-for-libtk8.6.dylib.patch ]; </ins> })

<ins> From f90278dac42135acd55200b7d2153f44d72fec53 Mon Sep 17 00:00:00 2001 From: Josef Knedl <josef.kemetmueller@aon.at> Date: Wed, 24 Feb 2016 00:37:40 +0100 Subject: [PATCH] Fix bad install_name for libtk8.6.dylib This follows: https://trac.macports.org/ticket/37395 and https://trac.macports.org/changeset/100816 Alternative would be to use Quartz build instead: https://sourceforge.net/p/tktoolkit/bugs/3048/ --- unix/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/unix/Makefile.in b/unix/Makefile.in index f21fdbb..1b89256 100644 --- a/unix/Makefile.in +++ b/unix/Makefile.in @@ -283,7 +283,7 @@ CC_SEARCH_FLAGS	= @CC_SEARCH_FLAGS@ LD_SEARCH_FLAGS	= @LD_SEARCH_FLAGS@ # support for embedded libraries on Darwin / Mac OS X -DYLIB_INSTALL_DIR	= ${LIB_RUNTIME_DIR} +DYLIB_INSTALL_DIR	= $(libdir) # support for building the Aqua resource file TK_RSRC_FILE		= @TK_RSRC_FILE@ -- 2.7.1 </ins>
Change:
, CVSSv3=9.8 (nixos-21.05) The package glances before 3.2.1 are vulnerable to XML External Entity (XXE) Injection via the use of Fault to parse untrusted XML data, which is known to be vulnerable to XML attacks. Scanned versions: nixos-21.05: . Cc Cc Cc
This was resolved by

Discussion:
{ stdenv, buildPythonApplication, fetchFromGitHub, isPyPy, lib <del> , future, psutil, setuptools </del> <ins> , defusedxml, future, psutil, setuptools </ins> # Optional dependencies: , bottle, pysnmp , hddtemp

buildPythonApplication rec { pname = "glances"; <del> version = "3.1.7"; </del> <ins> version = "3.2.3"; </ins> disabled = isPyPy; src = fetchFromGitHub { owner = "nicolargo"; repo = "glances"; rev = "v${version}"; <del> sha256 = "sha256-82ZD32dqRYGbGM/uyaJ5VqVZbhDZthiEcTihkV43JOU="; </del> <ins> sha256 = "1nc8bdzzrzaircq3myd32w6arpy2prn739886cq2h47cpinxmvpr"; </ins> }; # Some tests fail in the sandbox (they e.g. require access to /sys/class/power_supply):

propagatedBuildInputs = [ bottle <ins> defusedxml </ins> future netifaces psutil

meta = with lib; { homepage = "https://nicolargo.github.io/glances/"; description = "Cross-platform curses-based monitoring tool"; <del> changelog = "https://github.com/nicolargo/glances/releases/tag/v${version}"; </del> <ins> changelog = "https://github.com/nicolargo/glances/blob/v${version}/NEWS.rst"; </ins> license = licenses.lgpl3Only; maintainers = with maintainers; [ jonringer primeos koral ]; };
Change:
To make sure that we are on the same page: When I run ledger-autosync, it complains about a missing module. I expect it to run It prints:
Let me know if there is any other information you would like me to provide.
cc maintainer (btw, nlewo, your nick in is wrong)

Discussion:
sha256 = "f19fa66e656309825887171d84a462e64676b1cc36b62e4dd8679ff63926a469"; }; <ins> propagatedBuildInputs = with self; [ ofxclient ]; </ins> buildInputs = with self; [ <del> ofxclient </del> mock nose # Used at runtime to translate ofx entries to the ledger
Change:
qview support a list of images format, including webp: However, if you try opening a webp image in nixos, you get "unsupported image format". This format is listed as "optional", so it might just be a matter of activating it somehow. Steps to reproduce the behavior: qview with nex "qview " error message Image should be opened. Not needed Add any other context about the problem here.
I wonder if this is something we’d need to add in the nix Qt build itself.

Discussion:
<del> { mkDerivation, lib, fetchFromGitHub, qmake, qtbase }: </del> <ins> { lib , mkDerivation , fetchFromGitHub , qmake , qtbase , qtimageformats , qtsvg }: </ins> mkDerivation rec { pname = "qview";

buildInputs = [ qtbase <ins> qtimageformats qtsvg </ins> ]; patchPhase = ''

meta = with lib; { description = "Practical and minimal image viewer"; homepage = "https://interversehq.com/qview/"; <del> license = licenses.gpl3; </del> <ins> license = licenses.gpl3Plus; </ins> maintainers = with maintainers; [ acowley ]; platforms = platforms.all; };
Change:
blackbox-2.0.0 fails to build with test failures. Steps to reproduce the behavior: -env -i blackbox blackbox builds Please run and paste the result.
Don't really know why this would fail on darwin
fails on aarch64-linux but for a different reason

Discussion:
buildInputs = [ gnupg ]; <del> doCheck = true; </del> <ins> # https://github.com/NixOS/nixpkgs/issues/134445 doCheck = !stdenv.isDarwin && stdenv.isx86_64; </ins> checkInputs = [ expect
Change:
Project description is a PostgreSQL extension. The extension is a JSON output plugin for changeset extraction. Metadata homepage URL: source URL: license: platforms: unix, linux, darwin
Just curious why you need it? These days most tools support the builtin pgoutput...
I am using it in an event-driven architecture to publish events to GCP pubsub. JSON is easier to parse for my use case since I am using it in the application, and not just for replication.
I marked this as stale due to inactivity. &rarr;
I packaged this up over in It worked for my minimal testing, but I haven't done anything more involved with it yet.

Discussion:
<ins> { lib, stdenv, fetchFromGitHub, bison, flex, postgresql }: stdenv.mkDerivation rec { pname = "wal2json"; version = "2.4"; src = fetchFromGitHub { owner = "eulerto"; repo = "wal2json"; rev = "wal2json_${builtins.replaceStrings ["."] ["_"] version}"; sha256 = "sha256-EB+tCaILWsU9fDhqosl6EyMoYBd6SHISFfyxiZ9pNOk="; }; buildInputs = [ postgresql ]; makeFlags = [ "USE_PGXS=1" ]; installPhase = '' install -D -t $out/lib *.so install -D -t $out/share/postgresql/extension sql/*.sql ''; meta = with lib; { description = "PostgreSQL JSON output plugin for changeset extraction"; homepage = "https://github.com/eulerto/wal2json"; changelog = "https://github.com/eulerto/wal2json/releases/tag/wal2json_${version}"; maintainers = with maintainers; [ euank ]; platforms = postgresql.meta.platforms; license = licenses.bsd3; }; } </ins>

repmgr = super.callPackage ./ext/repmgr.nix { }; rum = super.callPackage ./ext/rum.nix { }; <ins> wal2json = super.callPackage ./ext/wal2json.nix { }; </ins> }
Change:
Presumably since , 's makes use of the new section which our binutils 2.35 doesn't understand, leading to warnings such as this one: More context can be found here: which describes the section Since binutils 2.36, supports the new note section. However we have been hesitant to update binutils so far (since it usually introduces a lot of breakage, e. g. see ). Open question: Is this a serious problem? Should we apply the patch from 2.36? Should we disable in the meantime where we use it? Build any haskell package on a platform that supports (with if necessary). <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Maintainer information:
I'd expect this would get fixed by PR
I've tried but that doesn't seem to fix it for me. It leads to a lot of warnings when building some custom packages so curious about a solution.
All warnings I've experienced so far have been fixed by this (or some other change).
I think this is fixed now? Haven't seen the warning for a long time now.

Discussion:
}; }); <ins> game = buildPythonPackage rec { name = "pygame-1.9.1"; src = fetchurl { url = http://www.pygame.org/ftp/pygame-1.9.1release.tar.gz; sha256 = "0cyl0ww4fjlf289pjxa53q4klyn55ajvkgymw0qrdgp4593raq52"; }; patches = [ ./pygame.patch ]; # auto confirming missing dependencies: # PORTMIDI and PORTTIME still missing patchPhase = '' sed -i 's@raw_input(.*@"1"@' config_unix.py unset patchPhase patchPhase ''; installCommand = "python setup.py install --prefix=$out"; propagatedBuildInputs = [ pkgs.SDL pkgs.SDL_mixer pkgs.SDL_gfx pkgs.SDL_net pkgs.SDL_sound pkgs.SDL_ttf pkgs.SDL_image pkgs.smpeg pkgs.libpng pkgs.libjpeg ]; }; </ins> genshi = buildPythonPackage { name = "genshi-0.6";

}; }; <ins> serial = buildPythonPackage rec { name = "pyserial-2.5"; doCheck = false; src = fetchurl { url = http://heanet.dl.sourceforge.net/project/pyserial/pyserial/2.5/pyserial-2.5.tar.gz; sha256 = "04gmpfb43ppc8cf1bvkz8r1gl0nrxc38kpfdqs40ib0d1ql25pgd"; }; }; </ins> tracing = buildPythonPackage rec { name = "tracing-0.6";
Change:
Hi, I didn't know that Hackage permits multiple versions under same number. They are called revisions, nix function interface doesn't have any argument for revision. I am updating packages, because of migration to GHC9 and I noticed a trend - several packages instead of bumping version - reuse old version and revision to disambiguate. The typical scenario - I set version (e.g. "1.0.0"), I need, and fake SHA to get the correct one on the first run, because it is convenient. nixpkgs gives me some SHA. It turns out that it picks SHA for oldest revision! I think I am not the one who use the function such a way. It would nice to check package version for multiple revisions and print hashes and dates for all of them! Minimum is to extend callHackageDirect comments about Hackage revisions.
Revision don't cause a new tarball to be uploaded, so the hash is indeed correct (and stays correct). Instead revisions need to be handled separately because the only thing exposed by hackage are the updated cabal files (so it is limited what you can change in a revision). That there's no convenient interface in for revisions is unfortunate indeed and we should consider adding this. In the meantime the following workaround should work:
I marked this as stale due to inactivity. &rarr;

Discussion:
# for any version that has been released on hackage as opposed to only # versions released before whatever version of all-cabal-hashes you happen # to be currently using. <del> callHackageDirect = {pkg, ver, sha256}: </del> <ins> callHackageDirect = {pkg, ver, sha256, rev ? { revision = null; sha256 = null; }}: args: </ins> let pkgver = "${pkg}-${ver}"; <del> in self.callCabal2nix pkg (pkgs.fetchzip { url = "mirror://hackage/${pkgver}/${pkgver}.tar.gz"; inherit sha256; }); </del> <ins> firstRevision = self.callCabal2nix pkg (pkgs.fetchzip { url = "mirror://hackage/${pkgver}/${pkgver}.tar.gz"; inherit sha256; }) args; in overrideCabal (orig: { revision = rev.revision; editedCabalFile = rev.sha256; }) firstRevision; </ins> # Creates a Haskell package from a source package by calling cabal2nix on the source. callCabal2nixWithOptions = name: src: extraCabal2nixOptions: args:

Type: drv -> drv */ <del> forceLlvmCodegenBackend = haskellLib.overrideCabal (drv: { </del> <ins> forceLlvmCodegenBackend = overrideCabal (drv: { </ins> configureFlags = drv.configureFlags or [ ] ++ [ "--ghc-option=-fllvm" ]; buildTools = drv.buildTools or [ ] ++ [ self.llvmPackages.llvm ]; });
Change:
Whenever I try to add a document using the web ui, it uploads and then waits forever to finish processing. Looking at the log in the same UI, I see the following lines: And when doing I see that it fails with . This is clearly due to the in the services, instead we should share between the and services (and potentially the too?). Steps to reproduce the behavior: a document forever The document should upload and finish processing correctly, being readable accross services. Please run and paste the result. Maintainer information:

Discussion:
PATH = mkForce cfg.package.path; PYTHONPATH = "${cfg.package.pythonPath}:${cfg.package}/lib/paperless-ng/src"; }; <ins> # Allow the web interface to access the private /tmp directory of the server. # This is required to support uploading files via the web interface. unitConfig.JoinsNamespaceOf = "paperless-ng-server.service"; </ins> # Bind to `paperless-ng-server` so that the web server never runs # during migrations bindsTo = [ "paperless-ng-server.service" ];

# Wait until server accepts connections machine.wait_until_succeeds("curl -fs localhost:28981") <del> with subtest("Document is consumed"): </del> <ins> with subtest("Create web test doc"): machine.succeed( "convert -size 400x40 xc:white -font 'DejaVu-Sans' -pointsize 20 -fill black " "-annotate +5+20 'hello web 16-10-2005' /tmp/webdoc.png" ) machine.wait_until_succeeds("curl -u admin:admin -F document=@/tmp/webdoc.png -fs localhost:28981/api/documents/post_document/") with subtest("Documents are consumed"): </ins> machine.wait_until_succeeds( <del> "(($(curl -u admin:admin -fs localhost:28981/api/documents/ | jq .count) == 1))" </del> <ins> "(($(curl -u admin:admin -fs localhost:28981/api/documents/ | jq .count) == 2))" </ins> ) assert "2005-10-16" in machine.succeed( "curl -u admin:admin -fs localhost:28981/api/documents/ | jq '.results | .[0] | .created'" ) <ins> assert "2005-10-16" in machine.succeed( "curl -u admin:admin -fs localhost:28981/api/documents/ | jq '.results | .[1] | .created'" ) </ins> ''; })
Change:
<!-- 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: sqlx-cli <!-- 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.5.5 desired version: 0.5.6 <!-- Search your package here: If no maintainer is listed for your package, tag the person that last updated the package --maintainers: Please tag this issue in your PR.

Discussion:
rustPlatform.buildRustPackage rec { pname = "sqlx-cli"; <del> version = "0.5.5"; </del> <ins> version = "0.5.6"; </ins> src = fetchFromGitHub { owner = "launchbadge"; repo = "sqlx"; rev = "v${version}"; <del> sha256 = "1051vldajdbkcxvrw2cig201c4nm68cvvnr2yia9f2ysmr68x5rh"; </del> <ins> sha256 = "sha256-Ir9n2Z3+dKCe2GLrVLV1dnxeKKtPJk/kd5wbtsKHtbw="; </ins> }; <del> cargoSha256 = "1ry893gjrwb670v80ff61yb00jvf49yp6194gqrjvnyarjc6bbb1"; </del> <ins> cargoSha256 = "sha256-MfLxzulcQSEcNGmer8m2ph2+lK2M3MN1PwAHDGzn3NQ="; </ins> doCheck = false; cargoBuildFlags = [ "-p sqlx-cli" ];