Package Details: keybase-bin 5.6.1_20210125164223+f3b21527b9-1

Git Clone URL: https://aur.archlinux.org/keybase-bin.git (read-only, click to copy)
Package Base: keybase-bin
Description: the Keybase Go client, filesystem, and GUI
Upstream URL: https://keybase.io
Licenses: BSD
Conflicts: kbfs, keybase, keybase-git, keybase-gui, keybase-release
Provides: kbfs, keybase, keybase-gui
Submitter: oconnor663
Maintainer: oconnor663 (keybase)
Last Packager: keybase
Votes: 144
Popularity: 2.10
First Submitted: 2016-06-22 16:52
Last Updated: 2021-01-25 19:22

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 Next › Last »

eschwartz commented on 2018-02-23 19:22

FWIW I've just updated keybase and added a new kbfs package in [community].

I'm not doing this suid-keybasehelper-and-extra-system-user shenanigans though, so if you use the community packages you'll just have to use ~/.local/share/keybase/fs or set the configuration yourself. ;)

eschwartz commented on 2018-02-23 17:42

No, they are using systemd-sysusers actually...

oconnor663 commented on 2018-02-23 17:11

@gdamjan thanks for pointing that out. It looks like what other services are doing is setting their users' homedirs to /. Does that sound right to you?

gdamjan commented on 2018-02-23 11:52

sudo /usr/bin/pwck -r

user 'keybasehelper': directory '/home/keybasehelper' does not exist

eschwartz commented on 2018-02-22 18:14

Currently /keybase is just a pointless symlink to /var/lib/keybase/mount1 which is itself a pointless symlink to ~/.local/share/keybase/fs for the first user account on the computer that used keybase.

It would make far, far more sense to simply drop the directory altogether. But the keybase developers do not want to break the expectations of people who expected to see /keybase and therefore any replacement at all would be rejected on the grounds that it, well, isn't /keybase.

gdamjan commented on 2018-02-22 18:10

@milouse it's probably better to put the path under /run/user/1000 ie. $XDG_RUNTIME_DIR

@oconnor663

jangho commented on 2018-01-27 02:13

PKGBUILD for keybase-bin-1.0.40_20180127012637+2887fffa7 seems to have a problem. The variable ${src_prefix} was used before it was defined.

Update: Fixed via https://github.com/keybase/client/pull/10363

oconnor663 commented on 2018-01-24 19:39

The "prerelease.keybase.io" domain is indeed a bit of legacy in our packaging layout that we haven't gone back to clean up yet.

noirbizarre commented on 2018-01-21 11:15

No offenses, it was just a suggestion.

It make sense when you know the process, but from a end user point of view the fact that binaries are updated on a daily basis is not documented anywhere, the only reference to versioning is the releases/tags on the github repository. There is also no "current release" reference on the keybase website, only install sections and link to the github repository. Another thing which mislead me: the binaries are downloaded from prerelease.keybase.io (which is also the case on the keybase website): I think this is why many of us where not understanding the releases flow and asked for stable releases (until now I was just thinking the website was outdated and still linking to prereleases)

eschwartz commented on 2018-01-21 00:31

This bin package is being updated by the upstream keybase release process, to correspond to the latest bin uploaded by the keybase team. It is therefore fulfilling the duty of all bin packages, to track, not "stable versions", but "binary releases from upstream". Which are not marked as betas or alphas or even RCs.

I am assuming for the sake of my sanity, that the keybase team are publishing the bin snapshots when they feel it is stable enough to, you know, publish as the official snapshots for all Debian and Fedora users ever. Given which, it seems to make sense to publish that as the unified release to all Linux platforms, including Arch Linux.

It is, after all, additionally linked and updated as the "current release" on the official website.

Speaking with my official TU hat on, I see no reason to get on their cases about this. In fact, if I were the package maintainer, I would endeavor to update just as frequently to the latest version being encouraged by upstream's primary download page...