jiebi/CodeConvo huggingface dataset:
Code change:
bower2nix = nodeEnv.buildNodePackage { name = "bower2nix"; packageName = "bower2nix"; <del> version = "3.1.0"; </del> <ins> version = "3.1.1"; </ins> src = fetchurl { <del> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.0.tgz"; sha1 = "f18a46335854ff9c5b4fe78f88309d7bf0631a1b"; </del> <ins> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.1.tgz"; sha1 = "wfzj1k6jkfnk1bkgbmpni59mdab8zk3p"; </ins> }; dependencies = [ sources."argparse-1.0.4"

Related discussion:
text: fetch-bower produces truncated nix-store entry when run under nix-build: Looking into the retrieved jquery in the nix store you can see jquery is actually missing: It works fine when trying to manually run it as a regular user: bower- generated by : run nix-build System: (16.09beta172. (Flounder)) Nix version: (nix-env (Nix) 1.11.4) Nixpkgs version: (16.09beta172.)
ping
Sorry for the delay I will test and merge today.
Hello thanks for your detailed report. I am getting slightly different results to you, so more investigation will be necessary. In my environment (NixOS 16.09 channel), there was no hash mismatch. Possibly something caused git to fail to download the jquery package. If it silently fails producing an incorrect result, then that is a bug in bower2nix which could be reported at
I am not sure this due to bower2nix. Fetch-bower is calling git and should handle the error's accordingly, no?
It consistently fails for me both on the latest unstable and 16.09 channels. Can you try updating your channels? My suspect was commit but I wasn't able to revert it cleanly to try it out.
By , I also mean . I have rolled the two programs into one repo. You are definitely right, is calling (indirectly, through the API), and should handle the error. I'm an avid subscriber to 16.09 and especially nixos-unstable, so have tested on those. Obviously it would be easier to fix the error handling if I can make fail myself. Do you have any further info about your setup which might be relevant? E.g. any proxy settings required for git to work. Can I also confirm that you are running before retrying ?
I don't have any proxy settings. Is it possible GitHub is rate limiting requests from bower? I found this thread interesting And yes I am running nix-store --delete before trying nix-build.
Hi are there any additional details I can provide? I am not that familiar with typescript or javascript, but I could try to narrow the issue down with some help.
How to reproduce: Expected output: bower package info json.
Code change:
bower2nix = nodeEnv.buildNodePackage { name = "bower2nix"; packageName = "bower2nix"; <del> version = "3.1.0"; </del> <ins> version = "3.1.1"; </ins> src = fetchurl { <del> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.0.tgz"; sha1 = "f18a46335854ff9c5b4fe78f88309d7bf0631a1b"; </del> <ins> url = "https://registry.npmjs.org/bower2nix/-/bower2nix-3.1.1.tgz"; sha1 = "wfzj1k6jkfnk1bkgbmpni59mdab8zk3p"; </ins> }; dependencies = [ sources."argparse-1.0.4"

Related discussion:
text: Actual output: nothing, not even an error message.
This problem is back. I can reproduce it by following the steps outlined in the top message. (latest nixpkgs-unstable) It did work for me a while ago though, so it looks like a regression. Did some digging around but I cannot figure it out. cc
Good catch, I think I've seen the same issue as well, but didn't bother (lack of time). Could be a different cause, but we have to start somewhere :)
Running produces correct result while -ing the following produces an output without jquery (just meta data)
Figured it out. Git doesn't see SSL certificates. I made it run with this expression I'll try to open a PR to fix this in nixpkgs. I'll also try to open a PR to bower2nix because there is a bug in it - missing SSL cert should not result in exit code 0.
Code change:
buildPythonPackage rec { pname = "localstack-ext"; <del> version = "3.2.0"; pyproject = true; </del> <ins> version = "2.3.2"; format = "setuptools"; </ins> src = fetchPypi { inherit pname version; <del> hash = "sha256-53pbt7kNaYQRsLb+OI8gLwR3cBE18ZKLZmG4aP1/93E="; </del> <ins> hash = "sha256-Ex5ZPlteDaiyex90QumucVdTTbpp9uWiBrvw1kMr++8="; </ins> }; postPatch = ''

Related discussion:
text: Steps to reproduce the behavior: localstack (from unstable) (version 3.2.0) localstack 2.3.0 works and so does (tagged because you bumped the version) (the channel is slightly messed up. I am using 23.11 but with flakes) Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
The new version requires too many dependencies to package up in a reasonable time frame and even includes circular ones. contains a revert to 3.0.0 which builds for me and shows the usage. Can you take a look if that works for you?
Sorry for the delay! Yes, the revert works well for me! Thank you!
Code change:
mlt shared-mime-info libv4l <del> glaxnimate </del> ]; qtWrapperArgs = [

Related discussion:
text: Rendering a project in Kdenlive with default rendering settings leads to the following error: Steps to reproduce the behavior: ( is the latest revision of at the moment of writing this) any clip to the timeline (for example, drag in an image) "Render..." "Render to File" You might need to use as your desktop manager to reproduce this issue. There is claiming that this crash doesn't happen on Plasma 6. I am using Plasma 5, but I am currently unable to verify if Plasma 6 would fix this issue (Plasma 6 is broken for me for unrelated reasons). Render should succeed. See issue for the previous instance of this problem. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Are you using the kdenlive matching to your desktop? Edit: nope, you are using the plasma 6 package. You want to use plasma5Packages.kdenlive.
is plasma6? Wow, that's quite a foot gun. Shouldn't it be called ? Also, fails with the same error.
It really should not matter, and will (once is entirely gone) be whatever versions upstream ships.
it seems that the problem either wasn't fixed or has resurfaced again? I was able to reproduce the exact same error with and (where is the latest revision of at the moment of writing this)
Please try again after the staging-next merge (which should make its way to unstable in a few hours).
I will. Could you explain why staging-next is relevant in this case, though? I am just curious. I checked using and in the github UI directly, and it seems that the changes from should be already present in revision .
staging-next reshuffles protobuf versions again.
I wasn't sure which staging-next merge you were originally talking about, so I tried the same thing with commits (current nixos-unstable), (current staging-next) and (current master) and I am still getting the same error. Can you reopen this issue, or should I open a new one?
Hm. Actually, I think that I figured out, what the problem is. It seems that actually saves some paths in .
Code change:
mlt shared-mime-info libv4l <del> glaxnimate </del> ]; qtWrapperArgs = [

Related discussion:
text: For example, my had the following lines: Deleting the line fixes the issue, but then adds it back again with the new path, so it will almost certainly eventually break again. I am honestly not sure, why does do this, but we should probably either patch this behavior or report it upstream.
That sounds very wrong because you have defaults from two different kdenlive versions in there.
I can tell you that I've never touched prior to this debugging session. I didn't even know it existed. Those lines seem to be automatically populated on demand. Most likely, these lines were simply generated at different times, and so they picked up different paths to the "current" version of . Also, the fact that these paths are different from each other is mostly irrelevant in this case. The real problem is that they are cached once and aren't updated when a different version of is used.
Code change:
, installShellFiles , git , unzip <del> , dmd_bin ? "${callPackage ./bootstrap.nix { }}/bin" </del> <ins> , dmdBootstrap ? callPackage ./bootstrap.nix { } , dmd_bin ? "${dmdBootstrap}/bin" </ins> }: let

Related discussion:
text: Describe the bug dmd keeps references to boostrap compiler. To Reproduce Steps to reproduce the behavior: Expected behavior dmd has no references to boostrap compiler Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(symphorien): nixpkgs: Maintainer information: Note: to prevent future regressions, it would be nice to add to the derivation ()
I marked this as stale due to inactivity. &rarr;
Still an issue
I marked this as stale due to inactivity. &rarr;
Code change:
<del> { stdenv, fetchurl, intltool, pkgconfig , gtk3, ibus, libhangul, python3 </del> <ins> { stdenv , fetchurl , substituteAll , intltool , pkgconfig , wrapGAppsHook , gtk3 , ibus , libhangul , python3 </ins> }: stdenv.mkDerivation rec {

Related discussion:
text: In executing ibus-setup-hangul, got this error message: .nix -rebuild switch ibus-setup-hangul in a shell System: NixOS 17.03.1584. (Gorilla) Nix version: 1.11.11 Nixpkgs version: 17.03.1584. Sandboxing enabled: build-use-sandbox = false
Might be due to . What was the reason to remove from dependencies?
I think that was because I noticed that it is propagated from some other package, but looking at this now it doesn't seem to be the case. I'll investigate this today!
This seems more deep than I thought. The bug is two-fold: script is not patched as needed for Python scripts; should be propagated from . However, only its output is propagated, so it's not as a Python library. I can fix the first one but not sure what to do about the second -- maybe we should change behaviour of this propagation in some way.
The same problem appears with anthy, and directly adding the same pyEnv to buildInputs like did in ibus definitely fixes the build fails (tested with both anthy and hangul), but the python environment isn't propagated by itself.
Code change:
# https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests # Retry the API query this many times <del> retryCount=3 </del> <ins> retryCount=5 </ins> # Start with 5 seconds, but double every retry retryInterval=5 while true; do

Related discussion:
text: example: This one is low on the massive bucket list, but extending the number of retries and the timeout between each retry will reduce friction.
This might be caused by , in which case increasing the timeout wouldn't help much. We can try though, PR appreciated!
please view
Code change:
NIX_LDFLAGS = "-lgcc_s"; configureFlags = [ <del> "--disable-kernel_crypto" </del> "--enable-cryptsetup-reencrypt" "--with-crypto_backend=openssl" ] ++ stdenv.lib.optional enablePython "--enable-python";

Related discussion:
text: See:
I've been using cryptsetup with an SSD and without kernel crypto to run my entire NixOS and didn't noted any performance issues, but I agree that my patch was a temporary workaround, so enabling the crypto module would be a better solution.
The option also breaks the feature of that can be used when installing nixos to reason about the speed of disk encryption
The NixOS test works with and the kernel userapace crypto API enabled in on at least 19.03. was updated to 2.0.6 in the meantime, maybe the bug was fixed? Haven't noticed anything in release notes. This API shouldn't in fact be need for LUKS, only for tcrypt and the benchmark. Did you also run the test or did you just notice that on your local machine? Do you have any non-standard config concerning the initrd?
Hmm, even with the test succeeds. We need more information.
I haven't ran any tests, I just tested it in my work laptop and in a VM used to isolate the issue. I used a non-standard initrd config only for debugging, but after finding the problem I used the standard one. The only strange thing I did was to have a LUKS2 encrypted volume, which isn't very common (or at least it wasn't at the moment I experienced the issue). In a few days I will try to boot my system both with and without kernel crypto to check whether it is necessary or not.
I can confirm that I still have problems booting my system when kernel crypto is enabled. I put this in my , in an updated unstable NixOS: With this configuration, my system boots. If I uncomment the line, it doesn't because it fails to unencrypt my root partition. I'm using LVM inside a LUKS2 partition.
Here is the result of using when mounting my LUKS2 volume with kernel crypto enabled. The last image is the most important. Sorry for pasting screenshots, I didn't have a flash drive to copy the logs. ! ! ! ! !
Thank you very much for your detailed analysis. :+1: Oh, LUKS2! Seems the userspace API is indeed needed for LUKS2 but not LUKS1. I'll try to adapt the test and fix this issue. There are probably just some modules missing.
Code change:
NIX_LDFLAGS = "-lgcc_s"; configureFlags = [ <del> "--disable-kernel_crypto" </del> "--enable-cryptsetup-reencrypt" "--with-crypto_backend=openssl" ] ++ stdenv.lib.optional enablePython "--enable-python";

Related discussion:
text: Commit introduced to the configuration of . This causes to no longer work, with the following message: Run , where is a truecrypt volume. system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The issue for re-enabling kernel_crypto is
It also breaks
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
I marked this as stale due to inactivity. &rarr;
are you sure this is still an issue? This seems to have been solved by . e.g. cryptsetup benchmark works just fine on my machine.
I did not check and do not care anymore. Thanks!
Code change:
<del> { alsa-lib, at-spi2-atk, at-spi2-core, atk, cairo, cups, curl, dbus, dpkg, expat, fetchurl, fontconfig, freetype, gdk-pixbuf, glib, gtk3, lib, libdrm, libnotify, libsecret, libuuid, libxcb, libxkbcommon, mesa, nspr, nss, pango, stdenv, systemd, wrapGAppsHook3, xorg, }: let version = "1.43.0"; rpath = lib.makeLibraryPath [ alsa-lib at-spi2-atk at-spi2-core atk cairo cups curl dbus expat fontconfig freetype gdk-pixbuf glib gtk3 libdrm libnotify libsecret libuuid libxcb libxkbcommon mesa nspr nss pango stdenv.cc.cc systemd xorg.libX11 xorg.libXScrnSaver xorg.libXcomposite xorg.libXcursor xorg.libXdamage xorg.libXext xorg.libXfixes xorg.libXi xorg.libXrandr xorg.libXrender xorg.libXtst xorg.libxkbfile xorg.libxshmfence (lib.getLib stdenv.cc.cc) ]; src = if stdenv.hostPlatform.system == "x86_64-linux" then fetchurl { url = "https://downloads.mongodb.com/compass/mongodb-compass_${version}_amd64.deb"; sha256 = "sha256-hzPhF0NGwv+Lm+q5SoS8qv10UmuKf4RarGMkEeCxp9w="; } else throw "MongoDB compass is not supported on ${stdenv.hostPlatform.system}"; # NOTE While MongoDB Compass is available to darwin, I do not have resources to test it # Feel free to make a PR adding support if desired in stdenv.mkDerivation { pname = "mongodb-compass"; inherit version; inherit src; buildInputs = [ dpkg wrapGAppsHook3 gtk3 ]; dontUnpack = true; buildCommand = '' IFS=$'n' # The deb file contains a setuid binary, so 'dpkg -x' doesn't work here dpkg --fsys-tarfile $src | tar --extract mkdir -p $out mv usr/* $out # cp -av $out/usr/* $out rm -rf $out/share/lintian # The node_modules are bringing in non-linux files/dependencies find $out -name "*.app" -exec rm -rf {} ; || true find $out -name "*.dll" -delete find $out -name "*.exe" -delete # Otherwise it looks "suspicious" chmod -R g-w $out for file in `find $out -type f -perm /0111 -o -name *.so*`; do echo "Manipulating file: $file" patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" "$file" || true patchelf --set-rpath ${rpath}:$out/lib/mongodb-compass "$file" || true done wrapGAppsHook $out/bin/mongodb-compass ''; meta = with lib; { description = "GUI for MongoDB"; maintainers = with maintainers; [ bryanasdev000 ]; homepage = "https://github.com/mongodb-js/compass"; sourceProvenance = with sourceTypes; [ binaryNativeCode ]; license = licenses.sspl; platforms = [ "x86_64-linux" ]; mainProgram = "mongodb-compass"; }; } </del>

Related discussion:
text: Package name: mongodb-compass Latest released version: <!-- Search your package here: --- Current version on the unstable channel: 1.43.0 Current version on the stable/release channel: 1.43.2 <!-- 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]:
Code change:
<del> { stdenv, fetchFromGitHub, cmake, qt4, libXfixes, libXtst}: </del> <ins> { stdenv, fetchFromGitHub, cmake, qt5, libXfixes, libXtst, git , webkitSupport ? true }: </ins> stdenv.mkDerivation rec { name = "CopyQ-${version}"; <del> version = "2.9.0"; </del> <ins> version = "3.0.3"; </ins> src  = fetchFromGitHub { owner = "hluk"; repo = "CopyQ"; rev = "v${version}"; <del> sha256 = "1gnqsfh50w3qcnbghkpjr5qs42fgl6643lmg4mg4wam8a852s64f"; </del> <ins> sha256 = "0wpxqrg4mn8xjsrwsmlhh731s2kr6afnzpqif1way0gi7fqr73jl"; </ins> }; <ins> patches = [ ./cmake-modules.patch ]; </ins> nativeBuildInputs = [ cmake ]; <del> buildInputs = [ qt4 libXfixes libXtst ]; </del> <ins> buildInputs = [ git qt5.full libXfixes libXtst ] ++ stdenv.lib.optional webkitSupport qt5.qtwebkit; </ins> meta = with stdenv.lib; { homepage    = https://hluk.github.io/CopyQ;

Related discussion:
text: Kdenlive build fails because CMake can't find QtConcurrent. Error: It appears to have been broken by some changes made to qtbase but I am not familiar enough with it to know what specifically. Changes between success and first failure: Latest Hydra failure: cc Attempt to install Kdenlive System: NixOS: 17.09pre107928. (Hummingbird) Nix version: nix-env (Nix) 1.11.9 Nixpkgs version: "17.09pre107928." Sandboxing enabled: build-use-sandbox = true
You need to modify the to We should send a patch upstream. This must be a required change since QT5.8.
Fixed by:
Code change:
, stdenv , fetchFromGitLab , writeText <ins> , substituteAll </ins> , meson , pkg-config , ninja

Related discussion:
text: For a few days, when booting my amd computer with plymouth enabled I can't enter my passphrase anymore. Pushing keys multiple times eventually end up in one key-press being accepted. Booting with instead of suddenly has no more issues with keyboard entries. Steps to reproduce the behavior: NixOS Unstable to and with a LUKS/ZFS Passphrase -presses are omitted Every key I hit will be used. <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- ? system: host os: multi-user?: sandbox: version: channels(pl): channels(root): nixpkgs: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Upstream bug report Fixed in upstream already
Code change:
gdrive = callPackage ../applications/networking/gdrive { }; <ins> gdrive3 = callPackage ../applications/networking/gdrive3 { }; </ins> gdu = callPackage ../tools/system/gdu { }; gfxreconstruct = callPackage ../tools/graphics/gfxreconstruct { };

Related discussion:
text: Project description To interact with Google Drive via the command line, there are and , both no longer maintained and now in my experience unable to authenticate with Google. still works, but it only targets public files and folders. There is a spiritual successor / fork of gdrive (2): gdrive 3 Metadata homepage URL: source URL: license: mit platforms: unix
Code change:
<ins> { stdenv , lib , config , fetchFromGitHub , testers , cmake , pkg-config , alsaSupport ? stdenv.hostPlatform.isLinux , alsa-lib , pulseaudioSupport ? config.pulseaudio or stdenv.hostPlatform.isLinux , libpulseaudio , jackSupport ? true , libjack2 , coreaudioSupport ? stdenv.hostPlatform.isDarwin , darwin , validatePkgConfig }: stdenv.mkDerivation (finalAttrs: { pname = "rtaudio"; version = "6.0.1"; src = fetchFromGitHub { owner = "thestk"; repo = "rtaudio"; rev = "refs/tags/${finalAttrs.version}"; hash = "sha256-Acsxbnl+V+Y4mKC1gD11n0m03E96HMK+oEY/YV7rlIY="; }; strictDeps = true; nativeBuildInputs = [ cmake pkg-config validatePkgConfig ]; buildInputs = lib.optionals alsaSupport [ alsa-lib ] ++ lib.optionals pulseaudioSupport [ libpulseaudio ] ++ lib.optionals jackSupport [ libjack2 ] ++ lib.optionals coreaudioSupport [ darwin.apple_sdk.frameworks.CoreAudio ]; cmakeFlags = [ (lib.cmakeBool "RTAUDIO_API_ALSA" alsaSupport) (lib.cmakeBool "RTAUDIO_API_PULSE" pulseaudioSupport) (lib.cmakeBool "RTAUDIO_API_JACK" jackSupport) (lib.cmakeBool "RTAUDIO_API_CORE" coreaudioSupport) ]; passthru.tests.pkg-config = testers.testMetaPkgConfig finalAttrs.finalPackage; meta = { description = "A set of C++ classes that provide a cross platform API for realtime audio input/output"; homepage = "https://www.music.mcgill.ca/~gary/rtaudio/"; changelog = "https://github.com/thestk/rtaudio/releases/tag/${finalAttrs.version}"; license = lib.licenses.mit; maintainers = with lib.maintainers; [ magnetophon ]; platforms = lib.platforms.unix; pkgConfigModules = [ "rtaudio" ]; }; }) </ins>

Related discussion:
text: Package name: Latest released version: 5.2.0 Current version on the unstable channel: 5.2.0 Current version on the stable/release channel: 5.2.0 Notify maintainers Note for maintainers: Please tag this issue in your PR.
Pending on
Code change:
beta = stable; legacy_340 = generic { <del> version = "340.104"; sha256_32bit = "1l8w95qpxmkw33c4lsf5ar9w2fkhky4x23rlpqvp1j66wbw1b473"; sha256_64bit = "18k65gx6jg956zxyfz31xdp914sq3msn665a759bdbryksbk3wds"; settingsSha256 = "1vvpqimvld2iyfjgb9wvs7ca0b0f68jzfdpr0icbyxk4vhsq7sxk"; persistencedSha256 = "0zqws2vsrxbxhv6z0nn2galnghcsilcn3s0f70bpm6jqj9wzy7x8"; </del> <ins> version = "340.107"; sha256_32bit = "0mh83affz6bim26ws7kkwwcfj2s6vkdy4d45hifsbshr82qd52wd"; sha256_64bit = "0pv9yv3x0kg9hfkmc50xb54ahxkbnyy2vyy4hj2h0s6m9sb5kqz3"; settingsSha256 = "1rgaa24acdyqa1rqrx56293vxpskr792njqqpigqmps04llsx703"; persistencedSha256 = "0nwv6kh4gxgy80x1zs6gcg5hy3amg25xhsfa2v4mwqa36sblxz6l"; </ins> useGLVND = false; patches = maybePatch_drm_legacy ++ [ ./vm_operations_struct-fault.patch ];

Related discussion:
text: Our current legacy nvidia driver of the 340 branch does not work with kernel version 4.19.2: NixOS is currently on the 340.104 version, but upstream is on 340.107: I hope that updating to 340.107 resolves the issue, but I don't understand how to update the different checksums for the nvidia driver. /nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev copying path '/nix/store/kic17fw8wil74k04kzh3dha43izrr9j3-bash-interactive-4.4-p23-dev' from ''... system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
The hashes are located at and can be generated like so: Please try:
Thanks alot for giving me a hand and teaching me how to get those four hashes! :+1: Updating to 340.107 indeed resolves this issue. PR: