Keybase is now at 1.0.17, and that has the cool new KeyBase FileSystem. Please bump.
The ebuild is already in tree. I haven't had time yet to play around with the filesystem. Gary, would you mind letting me know if it works for you?
(In reply to Nicolas Bock from comment #1) > The ebuild is already in tree. I haven't had time yet to play around with > the filesystem. Gary, would you mind letting me know if it works for you? Ah, there it is. You were quick. :-) Gimme 24 hours to play with it.
I have no clue how to mount the fuse. Doc somewhere? These keybase guys are not good on documentation....
Hi, one of the Keybase Linux devs here :-D Reading this ebuild (https://gitweb.gentoo.org/repo/gentoo.git/tree/app-crypt/keybase/keybase-1.0.17.ebuild), it looks like you all are building with a single `go build` step. For now that works to get the basic command line client running, and that was all we had for a while. But now we have all these KBFS bits (another `go build`) and the Electron-based GUI (built with NPM, more or less required for KBFS). Right now all those build commands are organized in https://github.com/keybase/client/blob/master/packaging/linux/build_binaries.sh. That script lays out important binaries in .../usr/bin and everything else in .../opt/keybase, in a way that's hopefully distro-neutral and easy to package. The deb- and rpm- and archlinux-specific packaging scripts wrap that one further. If you want to package KBFS/GUI bits, you can probably copy our AUR scripts almost verbatim: (building from source) https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=keybase-git (repackaging Debian binaries) https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=keybase-bin One of the reasons for our nonexistent documentation here (apart from our own laziness >.< ) is that essentially all of this is unstable. One of the major details we know we're going to want to change is, we should probably be shipping Keybase as 3 packages instead of 1. It's also likely that we'll see changes in the `-tags` we build with, some kind of systemd support, and who knows what else that might lead to breaking changes in our build/packaging. If anyone wants to get in touch with me, so that I can let you all know before changes land, please do.
Another reference point: The script that launches everything for the user at runtime (often from an autostart entry we create) is this one: https://github.com/keybase/client/blob/master/packaging/linux/run_keybase We stick that in .../usr/bin as part of packaging. You can also look at the way stdout gets redirected in there to see where logs end up, if you want to tail them.
(In reply to Jack O'Connor from comment #5) > Another reference point: The script that launches everything for the user at > runtime (often from an autostart entry we create) is this one: > https://github.com/keybase/client/blob/master/packaging/linux/run_keybase > > We stick that in .../usr/bin as part of packaging. You can also look at the > way stdout gets redirected in there to see where logs end up, if you want to > tail them. Well, then that needs to get in the Gentoo ebuild. Not there now: dagwood gpsd # eix keybase [I] app-crypt/keybase Available versions: 0.8.25 (~)1.0.15 (~)1.0.16 (~)1.0.17 Installed versions: 1.0.17(10:33:13 AM 08/15/2016) Homepage: https://keybase.io/ Description: Client for keybase.io dagwood gpsd # equery f app-crypt/keybase * Searching for keybase in app-crypt ... * Contents of app-crypt/keybase-1.0.17: /usr /usr/bin /usr/bin/keybase dagwood gpsd # ls /usr/bin/*keyba* /usr/bin/keybase The filesystem is a lot of why I want to try this.
(In reply to Jack O'Connor from comment #4) > Hi, one of the Keybase Linux devs here :-D Welcome, thanks for coming! You'll see Gentoo does things differently... > One of the reasons for our nonexistent documentation here (apart from our > own laziness >.< ) is that essentially all of this is unstable. Well, to each his own. I find it useful to write the documentation first. That way you know if your plan makes sense before you commit to code. As long as it all gets caught up by 1.0 time.
(In reply to Jack O'Connor from comment #4) > Hi, one of the Keybase Linux devs here :-D > Jack, thanks for the detailed comments! I will extend our current ebuild.
(In reply to Gary E. Miller from comment #6) > The filesystem is a lot of why I want to try this. The same here, I would love for this feature to work. I am working on it :)
I pushed app-crypt/kbfs-9999 to tree. Please give that a try. Since the folks at keybase haven't released anything there yet, the ebuild will pull in the most recent commit.
I'll close this bug. If you run into any trouble with kbfs please open a separate bug.
