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

Git Clone URL: (read-only, click to copy)
Package Base: keybase-bin
Description: the Keybase Go client, filesystem, and GUI
Upstream URL:
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: 143
Popularity: 1.49
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 »

noirbizarre commented on 2018-01-20 10:50

I was going to suggest the same thing. The practice on packages is to have: - xxxx: src package tracking stable versions - xxxx-bin: binary package tracking stable versions - xxxx-git: src package updated regulary to track the master changes In your case, keybase is already taken, so maybe just: - keybase-bin tracking stable versions - keybase-git tracking master on daily basis

aytekinar commented on 2018-01-18 09:36

I agree with @jemadux. Is there any chance to track only the stable versions, i.e., the tagged versions on GitHub? Right now, I feel that we are tracking the master, and I would not like to install all the new hashes.

I am not sure if that is possible at all, but could we set up keybase-git to track master and keybase-bin to track only the tagged versions (v1.0.39 as of January 18, 2018)?

oconnor663 commented on 2017-12-01 19:57

This package is always updated to the latest released Keybase version, and so far we've been publishing new Keybase versions daily on Linux. We could define a separate package that we only update on Mondays, or something like that, but so far slowing down updates just for the sake of slowing them down has seemed not worth it?

jemadux commented on 2017-12-01 19:05

why every time new update ?

yan12125 commented on 2017-11-23 18:09

@oconnor663: Thanks for pointing out the correct place. I've opened

oconnor663 commented on 2017-11-23 15:38

There's a discussion of signature checking below. Look for the comment containing the line "I worry the (small but non-zero) usability downsides of sig checking outweigh the (possibly actually zero) security benefits." If you want to discuss it more, it might be easier to file an issue in the upstream GitHub repo and tag @oconnor663.

yan12125 commented on 2017-11-23 15:30

+1 for verifying pgp signatures!

emlun commented on 2017-11-22 12:08

I suggest the following patch for enabling PGP signature checking.

diff --git a/PKGBUILD b/PKGBUILD
index 5fda4e1..56a3da9 100644
@@ -18,10 +18,13 @@ depends=(fuse gconf libxss gtk2) # don't change this without changing the SRCINF
conflicts=(keybase keybase-release keybase-git)
+ "${deb_pkgver}_i386.deb.sig"
+ "${deb_pkgver}_amd64.deb.sig"

package() {
@@ -43,5 +46,5 @@ package() {
rm -rf "$pkgdir/etc/cron.daily"

+sha256sums_i686=(994998f8093474330a1249e75963cacc948b8011ef5dff6e2e98085fa58448ba 'SKIP')
+sha256sums_x86_64=(35bd09c324828c125ecb68e83b3c54a36f8c48d61b09352593a62d64476f2802 'SKIP')

oconnor663 commented on 2017-09-19 14:34

@Eschwartz we should be hosting .sig files next to every new build file, including the older-than-most-recent ones, starting today.

oconnor663 commented on 2017-09-05 15:06

The /keybase path is deliberate, to make it possible for filepaths to be portable to other systems. (For example, /keybase/public/oconnor663/ It's possible to use a ~ to almost get the same effect, but there are many contexts where that doesn't work.

It's a cool patch though, for sure. Power users who want that kind of control will appreciate it.