Package Details: keybase-bin 6.2.8_20240306193933+e38523abbe-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: keybase
Last Packager: keybase
Votes: 146
Popularity: 0.80
First Submitted: 2016-06-22 16:52 (UTC)
Last Updated: 2024-03-06 19:51 (UTC)

Latest Comments

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

jangho commented on 2018-01-27 02:13 (UTC) (edited on 2018-01-27 03:12 (UTC) by jangho)

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 (UTC)

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 (UTC)

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 (UTC) (edited on 2018-01-21 00:33 (UTC) by eschwartz)

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...

noirbizarre commented on 2018-01-20 10:50 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

why every time new update ?

yan12125 commented on 2017-11-23 18:09 (UTC)

@oconnor663: Thanks for pointing out the correct place. I've opened https://github.com/keybase/client/issues/9671.

oconnor663 commented on 2017-11-23 15:38 (UTC) (edited on 2017-11-23 15:38 (UTC) by oconnor663)

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.

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