sublimeMerge: init at 1058 #47378
sublimeMerge: init at 1058 #47378
Conversation
pkgs/top-level/all-packages.nix
Outdated
| @@ -18806,6 +18806,10 @@ with pkgs; | |||
| pythonBindings = true; | |||
| }); | |||
|
|
|||
| sublimeMergePackages = recurseIntoAttrs (callPackage ../development/tools/sublime-merge/packages.nix { }); | |||
|
|
|||
| sublimeMerge = sublimeMergePackages.sublimeMerge; | |||
There was a problem hiding this comment.
fixing other comments, I'll explain this one though - this is a copy of the sublime text 3 package with as minimal changes as necessary to get it working.
| homepage = https://www.sublimemerge.com/; | ||
| maintainers = with maintainers; [ jonoabroad ]; | ||
| license = licenses.unfree; | ||
| platforms = [ "x86_64-linux" "i686-linux" ]; |
There was a problem hiding this comment.
There are only 64 bit binaries.
| done | ||
|
|
||
| # Rewrite pkexec|gksudo argument. Note that we can't delete bytes in binary. | ||
| sed -i -e 's,/bin/cp\x00,cp\x00\x00\x00\x00\x00\x00,g' sublime_merge |
There was a problem hiding this comment.
This does not seem to be necessary.
| installPhase = '' | ||
| mkdir -p $out/bin | ||
|
|
||
| cat > $out/bin/sublM <<-EOF |
There was a problem hiding this comment.
The short name is smerge not sublM, see the debian package.
| buildVersion = "1058"; | ||
| x64sha256 = "1yj3cg3z9421h36mgjprr94p4m0i4hl4ndi215bfp1i1b02rrva8"; | ||
| } {}; | ||
| } |
There was a problem hiding this comment.
Missing \n on the last line.
|
Could you add dev builds as well? https://forum.sublimetext.com/t/sublime-merge-dev-build-1060/39348 |
- short name smerge rather than sublM, - only support 64bit, - add current dev build, - remove unneeded rewrite.
| # when trying to run a build from within Sublime Merge | ||
| ln -s ${bash}/bin/bash $out/sublime_bash | ||
| wrapProgram $out/sublime_bash \ | ||
| --set LD_PRELOAD "${stdenv.cc.cc.lib}/lib${stdenv.lib.optionalString stdenv.is64bit "64"}/libgcc_s.so.1" |
There was a problem hiding this comment.
This is weird so. Does it not like libredirect? You could use makeWrapper to create sublime_bash directly instead of having the symlink first.
| #!/bin/sh | ||
| exec $sublimeMerge/sublime_merge "\$@" | ||
| EOF | ||
| chmod +x $out/bin/smerge |
| chmod +x $out/bin/smerge | ||
|
|
||
| ln $out/bin/smerge $out/bin/sublime_merge | ||
| ln $out/bin/smerge $out/bin/sublimeMerge |
There was a problem hiding this comment.
Why not just wrap to $out/bin/sublime_merge directly and then do the hard link?
|
|
||
| libPath = stdenv.lib.makeLibraryPath [glib xorg.libX11 gtk2 cairo pango]; | ||
| redirects = [ "/usr/bin/pkexec=${pkexecPath}" ] | ||
| ++ stdenv.lib.optional gksuSupport "/usr/bin/gksudo=${gksu}/bin/gksudo"; |
There was a problem hiding this comment.
Maybe we can convince upstream to not use absolute paths here.
There was a problem hiding this comment.
Is the sublime forum the right place to ask? @guillermooo
There was a problem hiding this comment.
I dropped something here, let's see: https://forum.sublimetext.com/t/sublime-tries-absolute-paths-for-pkexec-gksudo/39362
| @@ -18786,6 +18786,13 @@ with pkgs; | |||
|
|
|||
| sublime3-dev = sublime3Packages.sublime3-dev; | |||
|
|
|||
| sublimeMergePackages = recurseIntoAttrs (callPackage ../development/tools/sublime-merge/packages.nix { }); | |||
|
|
|||
| sublimeMerge = sublimeMergePackages.sublimeMerge; | |||
There was a problem hiding this comment.
You can do inherit (sublimeMergePackages) sublimeMerge sublimeMerge-dev;
|
Sublime Text now has |
|
closing in favor of #58994 |
Motivation for this change
Provide git client Sublime Merge addressing #47377
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)