jiebi/CodeConvo huggingface dataset:
Code change:
"-o", "kernel_cache,entry_timeout=60,attr_timeout=60,splice_write,splice_move", (char *)flatpak_file_get_path_cached (self->app_dir), <ins> diff --git a/src/builder-git.c b/src/builder-git.c index ef517adb..6ab095f0 100644 </ins> --- a/src/builder-git.c +++ b/src/builder-git.c @@ -44,7 +44,7 @@ git (GFile   *dir,

Related discussion:
text: Describe the bug flatpak-builder for some reasons can't use rofiles-fuse To Reproduce Steps to reproduce the behavior: build any app using flatpak-builder Expected behavior flatpak-builder should use rofiles-fuse. Screenshots Additional context Metadata system: host os: multi-user?: sandbox: version: channels(root): channels(piotrek): nixpkgs: Maintainer information:
installing solve this problem so maybe should be ?
We patch the paths to the executables to be hardcoded, so the program doesn't have to rely on something like ostree being installed. I believe one path isn't hardcoded with the current patch That looks it up in PATH, probably why it was working once you installed it.
cc
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 . 3. Ask on the on .
should fix that issue.
Code change:
inherit version; src = fetchFromGitHub { <ins> name = "ImHex-source-${version}"; </ins> fetchSubmodules = true; owner = "WerWolv"; <del> repo = pname; rev = "v${version}"; hash = "sha256-8Ehpk0TjE4itQ7D9Nx74plYwABVufuYmxfxyuSqak1c="; </del> <ins> repo = "ImHex"; rev = "refs/tags/v${version}"; hash = "sha256-8vhOOHfg4D9B9yYgnGZBpcjAjuL4M4oHHax9ad5PJtA="; </ins> }; <del> nativeBuildInputs = [ cmake llvm python3 perl pkg-config rsync ]; </del> <ins> nativeBuildInputs = [ autoPatchelfHook cmake llvm python3 perl pkg-config rsync ]; </ins> buildInputs = [ capstone

Related discussion:
text: Imhex on unstable and nixos-24.05 crashes. Output from the above command: Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
same as pending to merge
Ah, sorry, I only searched in opened issues.
Code change:
inherit version; src = fetchFromGitHub { <ins> name = "ImHex-source-${version}"; </ins> fetchSubmodules = true; owner = "WerWolv"; <del> repo = pname; rev = "v${version}"; hash = "sha256-8Ehpk0TjE4itQ7D9Nx74plYwABVufuYmxfxyuSqak1c="; </del> <ins> repo = "ImHex"; rev = "refs/tags/v${version}"; hash = "sha256-8vhOOHfg4D9B9yYgnGZBpcjAjuL4M4oHHax9ad5PJtA="; </ins> }; <del> nativeBuildInputs = [ cmake llvm python3 perl pkg-config rsync ]; </del> <ins> nativeBuildInputs = [ autoPatchelfHook cmake llvm python3 perl pkg-config rsync ]; </ins> buildInputs = [ capstone

Related discussion:
text: Imhex failed to start. Steps to reproduce the behavior: -shell -p imhex --run imhex Shows the following errors: Imhex start up normally. Adding -v, --verbose doesn't give more information. I don't know how to either.
Maintainer ping:
Can repro on master, but can't repro if I checkout and build from it, it should be possible to bisect and find out at what point this broke.
First bad commit: <details<summarygit bisect log</summary</details
Seems there's a bunch of upstream reports of breakage with glfw 3.4
This might be fixed with The PR was merged into 1.90.6, but 1.33.2 contains a vendored 1.90.4, which doesn't contain the fix. My guess is that updating from the current 1.33.2 in nixpkgs to the latest version upstream (1.35.3 as of today) should fix the issue, as the latter contains a vendored updated to version 1.90.8, which should contain the fix.
Looks like the PR was closed, are you talking about instead?
Yes, sorry. I got the PR reference from: ... which also references the commit you mentioned.
Still crashes on imhex 1.35.3, which I more or less expected.
After applying both PRs and , finally works on my system with the current . Note: both PRs were needed, either one alone didn't fix all the issues for me.
Solved, marking as closed.
Code change:
stdenv.mkDerivation rec { pname = "nct6687d"; <del> version = "0-unstable-2024-02-23"; </del> <ins> version = "0-unstable-2024-09-02"; </ins> src = fetchFromGitHub { owner = "Fred78290"; repo = "nct6687d"; <del> rev = "0ee35ed9541bde22fe219305d1647b51ed010c5e"; hash = "sha256-g81U+ngnsOslBDCQP51uDDyHPpCv9T/j+KmFUAQfz/M="; </del> <ins> rev = "f45b72a6ca335e20f8a2df5ee5d4e130916150d0"; hash = "sha256-2sAL6aXUafmm2DKIhqEoTSPZVmzu/lnTkpPznJndX3o="; </ins> }; setSourceRoot = ''

Related discussion:
text: Steps to reproduce the behavior: -rebuild with Just broke a few days ago. Right now I'm trying out Nyx's Cachyos Kernel, but I tried to change to pkgs.linuxPackages_latest. I have not tried to build it on vanilla kernel, as any rebuild fails right now due to this error. Something similar also happened with my framework laptop, but that seems to be resolved <!-- 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. Yes, its cachyos kernel, I to my config though and the issue persists. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Probably needs a update, I'll try looking at this when I get back.
Indeed there was a patch two weeks ago. Currently not near my desktop machine though.