Change:
mkdir -p $out/share/${pname}/ cp -R $src/* $out/share/${pname} <del> mkdir -p $out/bin ln -s $out/share/${pname}/${pname} $out/bin/ </del> mkdir -p $out/share/pixmaps <del> cp ${pname}.png $out/share/pixmaps/${pname}.png </del> <ins> cp gitkraken.png $out/share/pixmaps/ </ins> runHook postInstall ''; postFixup = '' pushd $out/share/${pname} <del> for file in ${pname} chrome-sandbox chrome_crashpad_handler; do </del> <ins> for file in gitkraken chrome-sandbox chrome_crashpad_handler; do </ins> patchelf --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" $file done <del> for file in $(find . -type f ( -name *.node -o -name ${pname} -o -name *.so* ) ); do </del> <ins> for file in $(find . -type f ( -name *.node -o -name gitkraken -o -name git -o -name git-* -o -name scalar -o -name *.so* ) ); do </ins> patchelf --set-rpath ${libPath}:$out/share/${pname} $file || true done popd <ins> # SSL and permissions fix for bundled nodegit pushd $out/share/${pname}/resources/app.asar.unpacked/node_modules/@axosoft/nodegit/build/Release mv nodegit-ubuntu-18.node nodegit-ubuntu-18-ssl-1.1.1.node mv nodegit-ubuntu-18-ssl-static.node nodegit-ubuntu-18.node chmod 755 nodegit-ubuntu-18.node popd # Devendor bundled git rm -rf $out/share/${pname}/resources/app.asar.unpacked/git ln -s ${git} $out/share/${pname}/resources/app.asar.unpacked/git # GitKraken expects the CA bundle to be located in the bundled git directory. Since we replace it with # the one from nixpkgs, which doesn't provide a CA bundle, we need to explicitly set its location at runtime makeWrapper $out/share/${pname}/gitkraken $out/bin/gitkraken --set GIT_SSL_CAINFO "${cacert}/etc/ssl/certs/ca-bundle.crt" </ins> ''; };

Discussion:
Since the gitkraken 9.5.1 -9.9.2 update (), gitkraken is not showing the commit graph anymore, making it effectively unusable. Steps to reproduce the behavior: (does not render commit graph) (works, renders commit graph) The context graph should be visible. after ! before ! I'm seeing the EGL erros described in without the flag. However, I'm also seeing them in the working versions and they disappear when running with , yet it still does not show the commit graph. Please run and paste the result.
I'm having the same issue
I had the same issue. The repositories on which it happened were corrupted. Try to run on the repositories where the commit graph doesn’t render. Only way I found to fix this was to get a fresh clone of the repository elsewhere and copy my current changes in the new repository location. If you have a better way to fix it, I’m all ears, since this is still happening on some of my repositories (but I don’t need to work on them rn so I didn’t bother doing that yet).
I'm afraid it's hitting all repos, even freshly cloned ones and also after running . This doesn't seem to be the problem here :grimacing:
Frack, that’s unexpected… It works fine on my machine. Though I’m locally using the updated Gitkraken 9.10.0, it used to also work with Gitkraken 9.9.2. Could you maybe try with the ?
Sure! :) Same issue, still even when cloning a fresh repo. The most fishy looking message seems to be . Maybe some patchelf forcing libGL into the rpath could help? I'm just speculating, though :smile: UPDATE: Adding libGL to the rpath resolves the issue with errors regarding missing libGL (something, at least) but changes nothing with respect to rendering the commit graph.
Shoot. Did you try running it with the silly debug messages ?
Not too much difference, I'm afraid: (this is current version 9.9.2 from master with libGL to the rpath, which reduces the noise). I've tried the flatpack version 9.10.0 which works flawlessly.
I was just thinking that it could be some NVidia issue but it is apparently not.

Doesn't work on my desktop with proprietary nvidia drivers under X11 but also not on my laptop with a Ryzen APU and mesa drivers on wayland (just to exclude another option).
Ok, my last guess would be to try to disable the new commit graph and see if that fixes your issue: . If it does, I’d advise you to open a support ticket with Gitkraken teams, they are pretty responsive (at least if you are a paying user :sweat_smile: )
Crazy, that actually worked! "This opt-out is temporary. Please contact us with any issues you have" <- done, and I'm actually a paying customer, so let's see :)
Glad to hear that! Please keep us posted :slightlysmilingface:
Alright, so I've got a mail from the Gitkraken team and they actually said that there were some issues with 9.9.2 and the new commit graph. While 9.10.0 from your branch was also not working initially, it does now after once disabling and the reenabling the new commit graph as suggested by their customer support. Don't ask me why, I've no idea :smile: Maybe some state somewhere. Anyway, as soon as your update from is merged I think we can close this issue. :) maybe you could add in your branch to the rpath, too?
From what I understand, this has to do with hardware acceleration? Not sure why this hasn’t been earlier… Since I can’t reproduce the same logs as yours, would you be kind enough to test it locally on your machine so I can include this change in my PR? Send me the patch in your reply so I can apply it in my branch.
I have just been reminded that I had to disable the bundled git binary to make the graph work. Could you try to: back the new commit graph () the « Git executable » to the non-bundled one () Make sure that you don’t see the errors related to with these settings. If you still see them, I believe a fix could be applied but it should be on its own PR IMO.
You are right! It is actually the git executable that causes the problem. If I switch back to the bundled one the commit graph disappears again. Interesting that this changes something but now we are smarter.

The libGL errors persist, though. I will make a separate PR adding it, then. If you feel we can close this issue please feel free to do so. :) It is just a workaround but a good one. :smile:
Confirmed I built 9.10.0 and changed Git Executable in the Experimental settings to use as opposed to the GitKraken bundled NodeGit. The commit tree is rendering again.
Actually I will patch 9.10.0 to include the binary from nixpkgs so we don’t have to perform this workaround. I’m currently struggling to fix the UI so that it shows the correct version being used, but it’s a detail. I might fix this in a separate PR. When 9.10.0 will be released, tweaking this setting won’t have any effect, since it will always use the binary from nix no matter what you choose.
I've filled an issue with GitKraken, to describe the broken behaviour of the bundled NodeGit on NixOS. !
The bundled and git-core are not subject to rpath patching. I've modified with the following, which corrects all those executables. However, this is not the final answer. It looks like also needs rpath patching, and the loop above should do that. But it doesn't. There is also a statically compiled version of nodegit in the same directory named , but I've not been able to coerce or to replace with
Ok, I will remove the bundled git patch from my PR and open a new one in draft until we can find a final solution to this issue. Thanks for the heads up.
Your nifty git patch is still the most robust solution right now :+1: So I'd keep it in your current PR for GitKraken 9.10.0. Perhaps we keep this issue open to try and find a solution that wrangles the bundled git executables so they work? I noticed the bundled and in GitKraken requires , so I've included that in my local build and corrected the rpath. Even so, the commit graph fails to render.The bundled NodeGit that invokes is linked against OpenSSL 1.1.1, which is now marked as insecure in nixpkgs 23.11, so not something we should ship. Not sure how to take that.

Here's my gitkraken config which is derived from your , adding , and correcting the rpath for the assorted git binaries.
In fact, there are more issues than the ones you mentioned with the bundled git binary. I noticed an issue with SSL (there is a ssl directory in the original bundled , which is missing in the one from nixpkgs) as well as an issue with configuration resolving. I’m using conditional includes and noticed that they are not picked up with the patch bundled . For these reasons, I think this feature should live outside the raw package update, which is very simple as it just updates the version and checksums.