GitHub Desktop for Linux?

[hamaminatu]

Please make Github Desktop available for linux user 😃

[shiftkey]

@hamaminatu this is an excellent question!

Currently our focus is on catching up to feature parity with the classic Desktop apps, and getting what we've built battle-tested, so I don't think this will be on our radar before we hit 1.0.

However I'm not aware of any current technical blockers for supporting Electron on Linux distros:

• dugite-native - the Git package we use in Desktop - has been tested on recent Ubuntu and Fedora distros, and the Atom team are using it
• Electron itself is built on Ubuntu 12.04 - I know other tools like VSCode support a bunch of distros, but maybe there's gaps in the official support for other platforms that we need to address
• there's various Electron API differences - both in availability and behaviour - between macOS, Windows and Linux. For an example, read the BrowserWindow docs to see just how many differences are identified. We'd already do work differentiating between macOS and Windows in areas of the app - this is more work we need to build in and test.
• what platform resources are there for the various Linux window managers that are available? We like to adhere to the macOS Human Interface Guidelines and the Windows Design Guidelines as much as possible.

We want to ensure a Linux version has the same high standard of quality as the other platforms we support, and given our lack of in-house expertise with the Linux ecosystem we'd love to get the community involved with this effort. So if you care to help us with knowledge, platform experience or testing, please upvote this issue or comment with how you can help!

We can also open in the interim to lay this groundwork, like #273, so we can steadily move towards this goal.

[cruzerld]

I'm a Linux / Windows / Mac desktop dev and i have some expertise in a few different ways of setting up apt and rpm repos. I've set some up manually on S3 and have used Artifactory to host repos as well. I feel like most node / electron tools pretty much stopped at building the .deb and .rpm so if interested maybe I can build a package or two to help out there? I've also built an .arch package in the past but that was a while back.

[ziggy42]

For the packaging part, you should also consider appimages, snaps or flatpaks to support multiple distributions with a single package.

[introwit]

Have used the GitHub desktop app for windows for quite a long time before switching to Ubuntu this year, so I could help with testing it out on Linux and give my feedback whether it's the same experience and how the app performance is compared to the other platform versions.

[shiftkey]

Tagging this as future-work as our 1.0 work and stabilization is the current focus.

[hanjiexi]

what platform resources are there for the various Linux window managers that are available? We like to adhere to the macOS Human Interface Guidelines and the Windows Design Guidelines as much as possible.

@shiftkey

GNOME HIG: https://developer.gnome.org/hig/stable/
KDE HIG: https://community.kde.org/KDE_Visual_Design_Group/HIG

Electron-based apps tend to work the same on all desktops, but if you do want to know where to focus your efforts, I suggest making sure it works great on GNOME, since that is the default (or will be soon) for the two most popular and commercially-supported distributions (Ubuntu and Fedora) as well as for Debian.

[picandocodigo]

I got it working on my system! (Debian GNU/Linux 9) I have never used Electron before and have very little experience with Node, so it took some workarounds. You can check the work in progress in my fork. There's still lots of stuff to do but it works!

[prijindal]

@picandocodigo
Works on Arch linux (4.9.27-1) with GNOME (3.24.2)

[lilianmoraru]

People seem to report of it working.
Linux is open-source, one can easily test the app in a VM(and Travis is already set).
Seems just like an extended "thank you" to Linus Torvalds.

[ahmed-taj]

I'm a Ubuntu user and would love you contribute and test the Linux version. At least I can then remove the slow Win10 (VM) I currently use for contribution 😅

[prajapati-parth]

For the packaging part, you should also consider appimages, snaps or flatpaks to support multiple distributions with a single package.

@ziggy42 VS Code is open sourced. We could use that for packing reference.

Electron-based apps tend to work the same on all desktops

@hanjiexi Agreed. Also GitKraken is an excellent example for this.

[ziggy42]

@prajapati-parth I'm fine with .deb and .rpm (I only use Ubuntu and Fedora so I'm covered 😄 ), but there are also examples using Appimages, like Microsoft BotFramework-Emulator.

Anyway, as long as you don't only ship debs, I'm fine 👌

[ankibalyan]

I'm also a ubuntu user, would love to see github on linux, also I'd like to go from 0.1 stage itself for testing.

[gengjiawen]

I have use travis ci to build github linux client, anyone interested can give it a try. Binary download : https://github.com/gengjiawen/desktop/releases.

[hron84]

@gengjiawen the 0.5.4 release has no binary. What is the difference between alpha2 and final 0.5.4?

[hron84]

Also, I wanna state here 0.5.4-alpha2 is works like a charm. I just downloaded yesterday, but can't wait to be GitHub officially on Linux.

[gengjiawen]

@hron84 Use the alpha version, since the linux version has not been fully tested. The 0.5.4 tag is not what i want, but github dont allow you to delete a tag release, just ignore it.
And also glad to hear it works.

[hron84]

@gengjiawen OK, thanks for the reply. Random tips: ship an icon with deb-rpm files, and also add a Category field to the .desktop file. If you can point me to the linux build script, I can make you few modifications to ship better packages later.

[gengjiawen]

You can fork my repo and change it (branch ci_build). The config file is the root package.json. And if you want other linux distro, you can config this file too. I hope Github desktop team will consider switch to electron builder.Because with electron builder we can use travis ci and appveyor to build multi platform binary.
Have fun :)

[hron84]

@gengjiawen next week i will check it out.

[hamaminatu]

hope it will available in AUR too 😄

[ankibalyan]

@gengjiawen tried 0.5.4 with source compilation, its working fine, will keep on testing.

[kleinen]

Seems I am getting hung up on 2FA code entry when connecting to Github Enterprise. Works on Windows/Mac just fine, but Linux seems to never finish verifying the code. If anyone wants any data or info, let me know what you want me to gather (and how to get it since I am not experienced in the ways of Electron/Node).

[kleinen]

I would also be a huge proponent for this feature as an enterprise customer that would like to have this for 300+ people. I've been working my account rep to see if they can help drive the priority of this. 👍

[lypborges]

@picandocodigo I tried your fork last night. But didn't work. I think it's because I'm using node x64 arch or maybe I'm missing something.

 lypborges  ~/Develop/GitHub/desktop  master  npm start                                                ✓  1732  22:30:14 
npm WARN lifecycle The node binary used for scripts is /home/lypborges/.asdf/shims/node but npm is using /home/lypborges/.asdf/installs/nodejs/7.10.0/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

> @ start /home/lypborges/Develop/GitHub/desktop
> cross-env NODE_ENV=development node script/start

I dunno how to run on x64 :(

npm ERR! Linux 4.8.0-52-generic
npm ERR! argv "/home/lypborges/.asdf/installs/nodejs/7.10.0/bin/node" "/home/lypborges/.asdf/installs/nodejs/7.10.0/bin/npm" "start"
npm ERR! node v7.10.0
npm ERR! npm  v4.2.0
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @ start: `cross-env NODE_ENV=development node script/start`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the @ start script 'cross-env NODE_ENV=development node script/start'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the  package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     cross-env NODE_ENV=development node script/start
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs 
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls 
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:

I'll keep trying, but If you have any tips. Tks 🚀 🐧

[shiftkey]

Seems I am getting hung up on 2FA code entry when connecting to Github Enterprise.

@kleinen this might be #1628 - could you confirm which version of GitHub Enterprise you are connecting to?

[kleinen]

My company recently upgraded to v2.9.

[shiftkey]

@kleinen please open a new issue with as much information as you can provide so we can investigate further...

[picandocodigo]

@lypborges I am running x64 too. I used to see that same error at first but solved it somehow along the way. Try updating the branch and running npm install (I guess this is necessary to update any libs from commits in master), npm run build:dev and then npm start again, see if that solves the problem for you?

By the way, I'm constantly updating my linux branch to keep it in sync with master.

[lypborges]

@picandocodigo I was running on the wrong branch...uihauihaui. Tks.

[kleinen]

@shiftkey Done! #1753

[rlabrecque]

I don't use linux much but should g++-4.8 gcc-4.8 be replaced with build-essential?

[hron84]

@kleinen Alpha works on Ubuntu 16.04.2, even with MFA

[probonopd]

@gengjiawen thanks for the AppImage, works for me on Ubuntu 16.04.
https://github.com/gengjiawen/desktop/releases

[liberodark]

Please make a linux version !

[probonopd]

Providing an AppImage would have, among others, these advantages:

• Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

[solinium]

Thanks @gengjiawen
Works for me on Ubuntu 17.04 on XFCE
EDIT: pushing and pulling doesn't work by default, compiling it with libcurl4-openssl-dev it seems will fix the problem

[hron84]

@probonopd There is no need to advertise AppImage. GitHub does packaging on its own and I really hope they employ quite good engineers and developers to make a right decision how and where they publish their software. Also, a GitHub issue is not a right place to advertise your project.

Even if you had good intentions with that comment, it bothers others and also very offtopic relating to this issue because at this time the Linux version of this software is simply non-existent, thus there is nothing to package. So please, skip these comments next time. Thanks.

[probonopd]

Even if you had good intentions with that comment, it bothers others and also very offtopic relating to this issue because at this time the Linux version of this software is simply non-existent, thus there is nothing to package.

Sorry @hron84 but I have to disagree. In fact @gengjiawen has shown that it is entirely feasible to produce a working Github Desktop for Linux. He even provides a working Linux AppImage for download on https://github.com/gengjiawen/desktop/releases (albeit not yet size-optimized).

GitHub does packaging on its own and I really hope they employ quite good engineers and developers to make a right decision how and where they publish their software.

I hope that they have a look on the work @gengjiawen has done.

[hron84]

Yeah, @gengjiawen working on a Linux version of GitHub Linux, but this issue is at @github's own issue tracker and not in @gengjiawen's one. Your comment is still offtopic here. If you want to suggest something to @gengjiawen, you can simply try to contact him/her. GitHub issues are not a forum topics and not a messaging platforms. All developers here try to keep the topic directly related to the issue. Suggesting a packaging platform is OK if you just say "Hey, use AppImage, here's a link to it", but writing a marketing-smelling comment to an issue is nothing but advertising what is - I think - not what are GitHub issues are for. I hope everything you wrote here can be found on the AppImage's homepage, thus needless to copy-paste its content.

[probonopd]

I am directly staying on topic "Please make Github Desktop available for linux user", suggesting a potential solution, and gave reasons why I think this would be a good idea.

[greggwon]

I guess I would ask a different question and point in a different direction. Why hasn't Java been considered as a much more portable way to get a great desktop app working across a wide range of environments?

[kleinen]

@greggwon I very much find the java subject interesting and conversation-worthy, but maybe that would be a good point to break that out into another issue asking for a java-based client. Then we can discuss that as its a larger scope than just "need to get electron's support for linux to work".

[joshaber]

We're happy to review and accept pull requests adding Linux support 😄 There haven't been any that I've seen yet.

[shiftkey]

We've also been working on issues with the dependencies that Desktop needs for Linux support:

• improving the packaging size of dugite-native: desktop/dugite-native#51
• using dugite with different Electron setups (with some great help from @gengjiawen): desktop/dugite#96

[picandocodigo]

@brunofin They've already mentioned they don't have in-house expertise, and from a business point of view it probably doesn't make sense for them to spend resources for Linux. As a Linux user myself I'm not even using the app, I feel comfortable with the command line. But it'll be nice to have the tool available on Linux.

I would suggest those of us who've been tinkering with it to join forces. We know the app runs, but following steps could be:

1 - Make sure we make the tests running properly. Unit tests pass on my setup, but integration tests fail.
2 - Have a working Travis build for Linux.
I'd say these two would be the first things to tackle before thinking of packaging.

Once we get that working we can make a Pull Request. As they mentioned, we haven't really submitted Pull Requests with our stuff, and they're open to supporting Linux. So don't get mad at them, let's all just work together to get this moving forward 😄

[shiftkey]

@picandocodigo

1 - Make sure we make the tests running properly. Unit tests pass on my setup, but integration tests fail.
2 - Have a working Travis build for Linux.

I have a branch lying around that I started as a hack project that takes care of both of these: shiftkey#1. This only addresses the build and test steps.

I think the packaging changes that are necessary are the biggest bit of work that we need to size up (electron-packager has limited support for Windows and Linux packaging formats, and I know @gengjiawen has been looking at electron-builder which we might need to migrate over to as part of supporting this.

[joshaber]

@brunofin Please keep in mind we're all just people here, doing our best. There's no need to antagonize.

[ptomato]

Here's a pull request for Linux support: #2271

I'm doing this with the end goal in mind of submitting a recipe to @flathub in order to make the app available as a Flatpak package. Here's my initial attempt at packaging it: endlessm/github-desktop-flatpak#1
In order to build properly on Flathub I'll need to freeze all the dependencies with Yarn or something like that, but I haven't gotten around to that yet.

[shiftkey]

I've been having some troubles running my Linux branch since we upgrade to Electron 1.7.5 in #2582 - app refuses to launch, not seeing any errors on the terminal.

Has anyone else seen this? cc @gengjiawen

[gengjiawen]

@shiftkey Yes, I notice this too, but I have not got time to figure it why.

[shiftkey]

@gengjiawen thanks for confirming. Once this release settles down I'll trace it to whether it's something in Electron, a new dependency that needs to be installed, or something in how Desktop is being packaged and launched.

[gengjiawen]

I tried Windows and Mac too, they works fine. Though integration test failed on travis ci.

[gengjiawen]

@shiftkey Maybe a bug in code, I replaced the main.js with another project's, the electron window occurred.

Update:

1. change show: false to show: true in app/src/main-process/app-window.ts, the window occurred.
   Then in developer tool show the following error

Uncaught (in promise) Platform not currently supported for resolving editors: linux

I found a Fix: change code app/src/lib/dispatcher/app-store.ts, looks some compatibility issue introduced in 9b0c2e1

try {
  const editors = await getAvailableEditors()
  if (editors.length) {
    const value = editors[0].editor
    // store this value to avoid the lookup next time
    localStorage.setItem(externalEditorKey, value)
    return value
  }
} catch (e) {
  console.log(e)
}

3. We may need to do more to avoid such issue. Any special reason show: false is default option.

[joshaber]

@goldenfreemanchina part of your comment was deleted as a violation of the Desktop Code of Conduct as it is unprofessional conduct. You may consider this an official warning.

[KristijanZic]

Why don't you get in touch with the Ubuntu Snappy team? I'm sure they would be willing to assist you in packaging github-desktop as a snap package. You should open a topic on the forums at https://snapcraft.io/

[shiftkey]

Nice spot @gengjiawen!

Any special reason show: false is default option.

I think this is related to showing the main window after the content has been rendered (rather than showing a blank window initially): 2a591c8

That fits with the "cannot resolve editors" error you also found, as I think that code path is part of setting up the initial state, which would then prevent the renderer from raising the show-main-window event to then display itself.

Let's see if I can put together a fix for that to return an empty list rather than erroring...

EDIT: #2807 should get this back to a happy place

[zackeezy]

@picandocodigo I am trying to run your branch in Linux Mint 18.1 but it keeps getting stuck at

npm ERR! @ compile:tslint: `tsc -p tslint-rules`
npm ERR! Exit status 2

And when I tried to run npm run build:dev it errored out at WEBPACK] Errors building ask-pass.js and warned of a lot of generics being used wrong.

[picandocodigo]

@zackeezy my branch is way behind master and lots has changed since then. The build is set up on Travis for Linux (#2808), so I guess there's better support in the latest code. I'll try to update my branch as soon as possible. The branch might not even be necessary anymore, we'll see.

[zackeezy]

@picandocodigo So could i try to build this branch for linux, theoretically?

[shiftkey]

@zackeezy @picandocodigo please try the latest master branch here and these instructions to test out the dev version:

npm install
npm run build:dev
npm start

If you are encountering a specific error, I can probably help with getting to the bottom of that.

[zackeezy]

Wow it worked. It opened with the developer tools open for some reason, but yea, it works. My only question now is how to have it runnable from the start menu.

[shiftkey]

@zackeezy that's the packaging step which we haven't gotten to yet. Some progress is underway in #2300 but I need to get back and update that with some current thoughts...

[zackeezy]

@shiftkey I'm just happy I have the gui version on my computer now. I use a bash script to run Minecraft and several other programs so I won't be too upset if I have to set one up for Github Desktop, too.

[cbluth]

RE: #1525 (comment)
@shiftkey those instructions fail if the .git directory is missing (downloaded via master.zip).

[zackeezy]

@cbluth I cloned the repo from command line. Doing so and then doing what he said makes it work.

[shiftkey]

@cbluth that's likely due to us embedding the SHA in the webpack configuration - we recommend working from a clone of the repository.

[j-f1]

Maybe that should use git rev-parse HEAD instead — I had trouble building when I checked out a copy of the repo in a git worktree.

[shiftkey]

@j-f1 it is using that, except when we can't:

desktop/script/dist-info.js

Lines 199 to 208 in 0a90898

	function getSHA() {
	// CircleCI does some funny stuff where HEAD points to an packed ref, but
	// luckily it gives us the SHA we want in the environment.
	const circleSHA = process.env.CIRCLE_SHA1
	if (circleSHA) {
	return circleSHA
	}
	return revParse(path.resolve(__dirname, '../.git'), 'HEAD')
	}

Open to suggestions or scenarios we haven't yet encountered in a new tech-debt issue.

[probonopd]

@zackeezy that's the packaging step which we haven't gotten to yet.

@shiftkey: @gengjiawen has a working automated packaging process for making AppImages since May 18, perhaps you might consider upstreaming this.

[shiftkey]

@probonopd please see #2300 which is our ongoing discussion about this

[qrkourier]

I had to do apt install libsecret-1-dev before npm install on Ubuntu Zesty 17.04 because

Package libsecret-1 was not found in the pkg-config search path.                                           
Perhaps you should add the directory containing `libsecret-1.pc'                             
to the PKG_CONFIG_PATH environment variable                                                                
No package 'libsecret-1' found                                          
gyp: Call to 'pkg-config --libs-only-l libsecret-1' returned exit status 1 while in binding.gyp. while trying to load binding.gyp

I also nuked and re-cloned the repo because there were some errors that I suspect were caused by building modules with different versions of Node. It worked with v8.6.0.

[Croydon]

I also had to install libsecret and a few others libraries on Fedora+KDE.

[shiftkey]

If someone wants to add the packages they install for their distribution so we can improve the setup documentation I'd be more than happy to collaborate and review.

[mikelpint]

I have written one for the AUR long time ago.

[appelgriebsch]

I did a recent build (v1.0.3) on my Fedora 26 VM and packaged it as RPM and DEB. Could test the RPM already and it worked fine. Feel free to use it (https://github.com/appelgriebsch/dotFiles/releases/tag/0.1.0)

[Deams51]

@shiftkey Made a PR for Ubuntu 16.04 packages #3157

[nz4r]

Github Desktop Worked On Backbox5.1 (ubuntu 16.4) THANKS!

[beruic]

@Deams51 Any idea off when to expect it from official channels?

[ilhamdoanggg]

linux no needed it

[nkkollaw]

@appelgriebsch: I've installed it on elementary OS, and it does work, but it for some reason cannot get window controls correctly (maximize button is missing), and the window cannot be resized vertically.

Awesome work, don't get me wrong. Just thought I'd leave some feedback.

A snap would be pretty nice!

[Roychenlei]

i need linux

[nkkollaw]

@Roychenlei linux no needed it

[xalalau]

+1 for Linux

[RevoluPowered]

I need it too. Snapd or flatpak

[Serkan-devel]

Appimage support when?

[qaamal]

+1

[vitalkanev]

I might want to get PPA from Launchpad somewhere.

[ptomato]

Please don't post "+1" or "When is it happening" comments. It creates noise for everyone else and makes the real discussion harder to follow. You can subscribe to the issue to receive notifications, or add a 👍 reaction at the top of the page to show that you want this.

[mitar]

I tested this out yesterday and it works pretty well, but there are some simple issues.

I used update-electron-builder-linux branch (#3407) and followed setup process here to prepare the environment. I used Docker and ubuntu:trusty base image (to use the same as it is used in TravisCI) to do all the work. I tested resulted packages on Ubuntu 17.10.

So after installing dependencies, I called yarn run package to get packages built into dist subdirectory. I found three issues:

• appimage, it does not start: #3425
• Debian package:
  • it has confusing package name, just desktop: #3424
  • it does not work because of a broken symlink: #3426

So after I fixed the broken symlink, GitHub Desktop started working for me through Debian package.

Contributions to fix all of that are welcome, if anyone is familiar how to do so.

[RevoluPowered]

Cool, I might contribute by uploading it to snapd as 'alpha'

@mitar I will also test this on Fedora and confirm it works. Do you use snapd? If so after I bundle it can you help test the snap?

[mitar]

For snapd, ideally, we should add it so that it is generated with yarn packages as well. I use Ubuntu 17.10, which supports snaps, so I can test it.

[TingPing]

I will add a Flatpak to Flathub the second an official release happens.

[ziggy42]

@TingPing do they only allow officially supported apps?

[vitalkanev]

I could create PPA via Launchpad.

[RevoluPowered]

okay, I'll see if I get time today to add support using 'yarn packages', if not I will have time tomorrow probably.

Working on a game at the moment so not had huge amounts of free time, but getting this running on Linux would be handy as I don't like git cola any more.

[shiftkey]

First off, thanks for everyone who has commented here and gotten involved with getting Desktop working on Linux! I wanted to take this moment to revisit this thread and then sketch out a way forward so we can make our Linux support better!

Feedback Themes

Looking over the current feedback here, it falls into a few distinct themes. I'll summarize them here and address them from the perspective of the core team.

• "I want a Linux version"

It's great to hear this passion and excitement, but without tangible feedback or actionable tasks we're a bit in the dark. Also, please don't +1 this thread - use the reactions!

• "I was able to run it up on XYZ distro but encountered a problem"

These sorts of things are great, because it gives us details about what you're using and what the issue is - whether it's a blocker or polish, whether its something we can fix or we can talk to the Electron team about. The more details included, the better!

• "I've made package of Desktop available for XYZ distro"

This is also great to hear! We're a small team trying to work on quality and feature stuff at the moment, so any people who can step up and help out are more than welcome. If you're happy to manage publishing updates when we make new releases available, feel free to submit a PR so we can promote it in this repository. This PR and the related issue is a good example.

• "I want a Linux build in XYZ package format"

We're currently leveraging electron-builder to generate packaged versions of Desktop, and the list of formats is large - formats not in that list will require contributions to electron-builder, and the Desktop team does not have the bandwidth to do this for the foreseeable future.

If you're interested in this space, there's a guide to getting Desktop up and running locally with instructions that cover some mainstream distributions.

The Next Steps

So how can we leverage the interest and passion here to move this issue along? Here's what I've been busy with lately...

Better Usage of electron-builder

Up until recently we had the ability to generate packages for RPM, DEB and AppImage using simple wrappers on top of electron-builder, but these needed some work:

• installers don't work as expected - e.g #3425, #3426
• installers aren't configured as expected - e.g. #3424
• support for other package formats

I've merged #3563 to get us back using electron-builder for our Linux package targets - this gives us access to everything that electron-builder supports for whatever targets we end up choosing.

Release Candidates

Ensuring we are generating quality installers requires testing time, and not everyone has the time to keep up with our development, let alone create their own installers and run them. So what if we used my fork (shiftkey/desktop) on GitHub and added new builds whenever new tags were pushed to the main repository?

Using tagged builds helps us correlate the source for a build for any bugs reported, without having to worry about how someone built the code and that they used the right source.

We just published the 1.0.11 update today for macOS and Windows, and as an early Christmas present to you all I've published the first release candidate here for you to try out.

What We Need From You

If you are interested in these release candidates: watch shiftkey/desktop as these builds are tagged and published. This will give me an idea of how many people are actively interested in helping out with this effort, beyond those who are just upvoting this issue out of interest.

If you encounter an issue with these release candidate installers, report an issue to my fork shiftkey/desktop with as much detail as possible. Do not submit an issue to the main repository. Any issues filed in the main repository will be closed with a note to file them in the right location.

There are a few reasons for this:

• I'm probably the most experienced one with these sorts of issues currently, and have a couple of setups to help with testing. Keeping this out of the main repository means the rest of the core team can focus on their priorities in the short-term, rather than having to triage these as part of their normal work.
• Having these issues in one spot means I can identify just how much work we have to do, and triage them whenever I have bandwidth. I can then organize getting things upstreamed as they're ready, and possibly ship interim release candidates over in the fork.
• By keeping this work in my fork, we avoid any potential confusion when we figure out what our "official support" story looks like.

If you are building from source and something isn't working as you expected, have a read of the documentation for the tools we are using:

• electron-packager options
• electron-builder linux configuration options

The right setting is probably something we've overlooked, hiding in one of those two places. I'll write up some documentation to help others with testing installers locally, to make it easier for people to dive into this.

If you think you've found a solution, please submit a PR to shiftkey/desktop explaining the change and what it fixes. If you're not quite sure, open an issue on the shiftkey/desktop fork explaining what you've found and where you think the problem lies. Maybe someone else has insight into the issue.

For any other questions or suggestions related to GitHub Desktop & Linux, please open an issue over on shiftkey/desktop. This will help me track feedback better and discuss things in more detail. You can continue to use this thread for general discussions, but the more interesting stuff should be over on shiftkey/desktop.

Closing Remarks

We haven't committed to too much work here, or been too specific with timelines, because we don't want to mess this up. The team here are sticklers for quality (and I say despite being the one who has broken the Linux build by accident) and we need your engagement and experience here to ensure we do this right.

With Christmas fast approaching, the team will be taking some time off over the next few weeks. We're gathering in January to reflect on the last year and plan for the year ahead, so the input from that will affect where we focus our efforts around this area in the short-term.

[SirFaenor]

AppImage works for me on Opensuse Leap 42.3 with this little hack:
ln -s /usr/lib64/libcurl.so.4 /usr/lib64/libcurl-gnutls.so.4
otherwise is reporting an error about failing to load shared libraries.
Thanks!!

[shiftkey]

@SirFaenor is this related to Git operations? I think this is desktop/dugite-native#42 which is an ongoing discussion about how to statically compile Git.

[SirFaenor]

@shiftkey I am not a os guru but I suppose it is. I can easily reproduce the error by removing the symlink:
/tmp/.mount_GitHubVyFZN6/app/resources/app/git/libexec/git-core/git-remote-https: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory
so it seems related to git-remote-https.
Sorry I didn't notice the issue you referenced.

[wboswall]

Why not just clone the windows version of Github desktop and make it available for Linux distributions? That would solve the problem.

[anowlcalledjosh]

@wboswall That's exactly what's happening; feel free to peruse the comment by shiftkey located four comments above yours.

[wboswall]

@anowlcalledjosh That's good to hear but why is it taking so long for it to be released?

[anowlcalledjosh]

@wboswall Take a look at the comment I mentioned above, look at the current issues, and read this comment too.