keybase: 1.0.18 -> 20170209.17b641d #22600
Conversation
|
@SuprDewd, thanks for your PR! By analyzing the history of the files in this pull request, we identified @aristidb and @carlsverre to be potential reviewers. |
|
Can we have the version that tracks master be named separately? This seems to be a random commit from master that happened in the last 6 hours. I would rather use "official" releases from their repo since this is security software. |
|
That sounds like a good idea. So something like But to justify these particular commits: this is the same version as you would get if you'd go to https://keybase.io/download and download the software. So this is, to some extent, an "official" release. In any case, I think we should go with your suggestion because of the reason you gave. If anyone wants to do that, feel free to take the lead. If not, I'll try to give it a go. |
|
NVM! I was going off of the latest release version on their GH. I just downloaded and verified that the version of keybase you get from https://prerelease.keybase.io/keybase_amd64.deb tracks master so I think this is a safe change. Possibly we should switch to installing from their release deb although that can be another change. IMO I am personally ok with running w/e keybase releases on their site - so I am ok with this replacing the package called keybase in nixpkgs. If other people want to run the last "official" tagged release we can add a "keybase-stable" package. |
|
I think that .deb archive now also contains their Electron desktop client. If we switch to using their .deb then we'll also get access to that. |
|
Yea it looks like that's the case. I would love to simplify into a single nix package based on the deb with a option to disable the fuse mount. Or if the fuse mount is just initialized by the desktop client then we can install everything and people can opt in based on how they use keybase. I personally only use the CLI client. |
|
The same applies to kbfs, which means we would no longer need to maintain a
separate package for that.
I did actually have a go (pardon the pun) at packaging the .deb earlier
today, but ran into an issue with patchelf, which seems to have some
trouble with go binaries (NixOS/patchelf#66).
There is a suggested workaround at the bottom of the thread, but it only
seems to work partially in this case. Some of the keybase commands seem to
exec the binary directly (circumventing the wrapper), and then it crashes.
Someone more experienced might get farther...
On Feb 9, 2017 23:12, "Brian McKenna" <notifications@github.com> wrote:
I think that .deb archive now also contains their Electron desktop client.
If we switch to using their .deb then we'll also get access to that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22600 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AALa5TAN4yodzENNMwl84ZtWl2SBgj1iks5ra51AgaJpZM4L8roi>
.
|
|
I think we've reached the conclusion that we want to package the .deb. If there are no objections I'll open an issue where we can discuss the next steps. I'll leave this and #22601 open in case someone wants to merge a short-term solution (especially for those that are eager to try out the new chat feature). |
|
Yup patchelf is currently totally messed up on go binaries. The best workaround is probably what you did which is wrapping the keybase binaries with a script that execs the binary with the nix loader. As you pointed out this can be circumvented when a binary tries to exec itself. I am currently investigating fixing patchelf so it works with ELF's produced by go since I am running into this issue quite often. |
|
Maybe we'll have to go a full FHS environment in the case we can't fix patchelf or the forking. |
|
I've got the start of a FHS environment here: https://github.com/puffnfresh/nix-files/blob/master/keybase.nix The daemon seems to start and the GUI opens but the GUI says that it can't connect:
|
|
Got it working once I ran keybase and kbfsfuse outside of the chroot environment. Will figure out a way to get that packaged. |
|
@puffnfresh Cool! Keep us posted. I'll withdraw the pull requests if you manage to package it. |
|
@puffnfresh looking forward to seeing the chroot'ed version. Curious how KBFS is going to react to having the mount point outside of the chroot. Will we need to mount it inside the chroot for things to work? On the patchelf front - I think I have found the bug that causes it to fail to work for go compiled ELF's - and I have an extremely hacky solution that seems to work (I successfully used it to patch the deb binary version of the keybase binary to a nix packaged ld). Going to keep pushing on that since it is widely applicable for us due to the prevalence of go binaries these days. Don't block on me though since getting an updated keybase in nixpkgs should be top priority. |
|
I think it'd be nice to have both keybase/kbfs clients as a separate option from the package that includes the electron app and everything. For one, I don't think there's a way to actually build electron apps deterministically so we're stuck using the precompiled deb instead of building from source. Also if you don't want the gui it's gonna be a really huge package just to get a couple go binaries. |
|
I think we should build keybase and kbfs using Go and I'll submit a PR for a "keybase-gui" attribute which uses the Debian package. |
|
fwiw i tried out this and #22601 and both seem to work for me |
Motivation for this change
keybase is out of date.
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)I'm bumping kbfs's version simultaneously in #22601. Both programs seem to be actively developed over at Keybase, but it seems that they've stopped making formal releases for keybase, and there were never any formal releases for kbfs. Instead they seem to be something like a rolling release (see https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/index.html). I picked the commits for keybase/kbfs based on (at the time of writing this) newest entry in that list.
This also fixes some warnings that were being generated due to a slight mismatch between the current versions (in nixpkgs) of keybase and kbfs. See #22375.