Search Criteria
Package Details: keybase-bin 5.9.3_20220216215910+c82d65a685-1
Package Actions
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.169295 |
First Submitted: | 2016-06-22 16:52 (UTC) |
Last Updated: | 2022-02-16 22:22 (UTC) |
Latest Comments
evybongers commented on 2022-01-06 11:53 (UTC)
@wget I just opened https://github.com/keybase/client/pull/24778 to have the dependencies updated.
wget commented on 2020-11-17 10:59 (UTC)
@keybase @oconnor663 would you mind patching this PKGBUILD to pull gtk3 dependencies instead since this commit is now merged for a bunch of time now? Thanks :)
oconnor663 commented on 2020-04-22 19:04 (UTC)
@milouse @zwork I've opened https://github.com/keybase/client/pull/23909.
zwork commented on 2020-04-21 02:24 (UTC)
I think the gconf requirement for this package ought to be removed, would that be possible?
milouse commented on 2020-01-07 12:17 (UTC)
I just checked today, I can confirm that this package run as expected without the gconf dependency. I cannot test further without the gtk2 deps, because it's still required by some other stuff on my machine.
eschwartz commented on 2019-08-16 19:18 (UTC)
It's unlikely to find desktop systems without gtk3 installed, which is I guess the only reason why this gtk3-using package which has a dependency on gtk2, works. Clearly, no one has kept track of what system dependencies are used by the mysterious thirdparty electron binary included verbatim in the package "because electron as a GUI programming paradigm". :p
(Once again, this is why I like using system electron.)
eschwartz commented on 2019-08-16 19:14 (UTC)
That should probably be revisited, then.
oconnor663 commented on 2019-08-16 18:28 (UTC)
@ava1ar see https://github.com/keybase/client/issues/7866
ava1ar commented on 2019-08-16 03:56 (UTC)
Why does it depend on gconf?
keybase commented on 2019-01-25 16:38 (UTC)
@securetodeath
Fixed.
securetodeath commented on 2018-10-27 13:05 (UTC)
Why isn't the source just https://prerelease.keybase.io/linux_binaries/deb* ?
oconnor663 commented on 2018-08-17 14:09 (UTC)
Today's glibc update included the fix for this issue. Thanks @nallekarhu and @Eschwartz for finding it.
oconnor663 commented on 2018-08-14 21:08 (UTC)
The testing version of the glibc package (https://www.archlinux.org/packages/testing/x86_64/glibc/) contains a temporary patch to mitigate this (https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/glibc&id=f2aaaac68876f6959c62ea09dcdda5d441bf4ff7). As soon as that lands we should be good.
dstokes commented on 2018-08-14 20:24 (UTC) (edited on 2018-08-14 20:26 (UTC) by dstokes)
You can patch the binary with glibc-2.27 as a workaround.
https://archive.archlinux.org/packages/g/glibc/glibc-2.27-3-x86_64.pkg.tar.xz
dmp1ce commented on 2018-08-14 17:57 (UTC)
I'm experiencing the same issue with the GUI not showing.
electron /opt/keybase/resources/app/
works for me.oconnor663 commented on 2018-08-07 22:19 (UTC)
@Eschwartz thank you so much for all the work you do around these packages. (@nallekarhu you were totally right.) I'm away from work for a few months, so my response times are longer than usual on issues like this.
electron /opt/keybase/resources/app/
seems like the workaround until https://bugs.archlinux.org/task/59550 is fixed. In the longer term, I agree with @Eschwartz that depending on system electron is the right play. (One of the frustrations there is that distros other than Arch will probably still need to ship the electron binaries, since we can't depend on their system packages being recent enough.)eschwartz commented on 2018-08-07 18:13 (UTC)
Okay, the problem is that using prebuilt electron binaries is somehow breaking since the glibc 2.28 update. See https://bugs.archlinux.org/task/59550
Also if you use the keybase-gui package I maintain in [community] you will not have this issue (although you might have other issues like https://github.com/keybase/kbfs/issues/1655 which I have submitted pull requests to fix, but without luck).
vendion commented on 2018-08-07 18:10 (UTC)
I'm running into this issue as well, I've even tried reinstalling the electron package with pacman then rebuilding and installing this package.
Running /opt/keybase/Keybase results in a seg fault whereas electron /opt/keybase/resources/app/ works
eschwartz commented on 2018-08-07 17:22 (UTC)
Can you try running both:
and
nallekarhu commented on 2018-08-07 05:58 (UTC) (edited on 2018-08-07 06:10 (UTC) by nallekarhu)
@oconnor663 the problem started right after updating to linux 4.17.12-arch1-1 this morning. We actually have two computers with linux 4.17.12-arch1-1 having the problem and a third Arch still with linux 4.17.11-1 that shows no problems. But I filed a bug with Keybase on Github nevertheless.
oconnor663 commented on 2018-08-07 04:31 (UTC)
@nallekarhu that might not be Arch specific. Could you file a bug with the regular Keybase project please?
nallekarhu commented on 2018-08-06 23:51 (UTC)
Keybase is running, but can't start gui. I see errors in journalctl: [ERRO keybase main.go:90] 001 dial unix /run/user/1000/keybase/keybased.sock: connect: no such file or directory ... keybase.gui.service: Main process exited, code=dumped, status=11/SEGV ... keybase.gui.service: Failed with result 'core-dump' Also in dmesg: [ 662.304095] Keybase[5508]: segfault at b87650 ip 0000000000b87650 sp 00007fff392c1d18 error 15 in Keybase[200000+160c000]
oconnor663 commented on 2018-08-06 00:18 (UTC)
@badpixelbr it sounds like you did a Ctrl-C during a previous install or something like that. Probably (hopefully) not an issue specific to this package. Take a look at the solutions mentioned here: https://bbs.archlinux.org/viewtopic.php?id=220552
badpixelbr commented on 2018-08-05 20:49 (UTC)
cant update keybase. when run makepkg -sriC at the end i have:
resolving dependencies... looking for conflicting packages... warning: could not fully load metadata for package keybase-bin-2.5.0_20180803162902+dee7010d7a-1 error: failed to prepare transaction (invalid or corrupted package) ==> WARNING: Failed to install built package(s).
and previous instalation cant work after try to update. after i remove keybase package and try to install again i have the same error.
axionl commented on 2018-05-30 00:50 (UTC)
keybase-bin E: Missing custom license directory (usr/share/licenses/keybase-bin)
oconnor663 commented on 2018-03-04 20:05 (UTC)
We're working on replacing the "mount helper" entirely with a small root process that will serve symlinks pointing to a user-specific mount under your homedir. That should both avoid some security issues and support the "multiple users on the same system" case properly for the first time. So in short, all of this stuff is in flux. (Folks who prefer to disable all of this, see https://github.com/keybase/client/pull/10724.)
eschwartz commented on 2018-03-04 00:10 (UTC)
@eduard, see https://github.com/keybase/client/issues/10487 and note that the latest git version of keybase will "fix" this by simply running the mount helper as SUID root.
eduard commented on 2018-03-03 07:46 (UTC)
/usr/bin/run_keybase: line 121: 4298 Segmentation fault keybase-mount-helper -user-mount "$mountdir"
gdamjan commented on 2018-02-25 18:03 (UTC)
@Eschwartz I agree completely with you.
eschwartz commented on 2018-02-25 17:53 (UTC) (edited on 2018-02-25 20:37 (UTC) by eschwartz)
This obviously requires something to perform the symlinking. The keybasehelper user and suid binary manage this to ensure that /keybase remains a symlink to wherever your kbfs mountpoint is truly located. This achieves no goal other than to ensure that people can reference /keybase and the filepath will work everywhere... assuming that by everywhere you mean on single-user systems...
So:
1) it doesn't even really work entirely, and maintaining this legacy symlink is inferior to simply using the correct location.
2) It requires having yet another /etc/passwd entry, and on top of that requires running a suid binary -- which is admittedly not so bad considering that it only runs as a restricted user account. https://github.com/keybase/client/pull/10250 Now instead of a world-writable mountpoint directory in root, there is a symlink in root to a symlink owned by a suid binary that points to a mountpoint.
Since I'm the one who is packaging the community package, I'm the one who gets to say I won't implement this, and people should just join the future and use ~/.local/share/keybase/fs or configure their own mountdir via
keybase config
. ;)gdamjan commented on 2018-02-25 17:30 (UTC)
What exactly is "suid-keybasehelper-and-extra-system-user shenanigans"?
setting homedir as / for a uid that doesn't do much, is fine
eschwartz commented on 2018-02-23 19:22 (UTC)
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 (UTC)
No, they are using systemd-sysusers actually...
oconnor663 commented on 2018-02-23 17:11 (UTC)
@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 (UTC)
sudo /usr/bin/pwck -r
user 'keybasehelper': directory '/home/keybasehelper' does not exist
eschwartz commented on 2018-02-22 18:14 (UTC)
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 (UTC)
@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 (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 themaster
changes In your case,keybase
is already taken, so maybe just: -keybase-bin
tracking stable versions -keybase-git
tracking master on daily basisaytekinar 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 trackmaster
andkeybase-bin
to track only the tagged versions (v1.0.39
as of January 18, 2018)?oconnor663 commented on 2017-12-01 19:57 (UTC)
jemadux commented on 2017-12-01 19:05 (UTC)
yan12125 commented on 2017-11-23 18:09 (UTC)
oconnor663 commented on 2017-11-23 15:38 (UTC) (edited on 2017-11-23 15:38 (UTC) by oconnor663)
yan12125 commented on 2017-11-23 15:30 (UTC)
emlun commented on 2017-11-22 12:08 (UTC)
oconnor663 commented on 2017-09-19 14:34 (UTC)
oconnor663 commented on 2017-09-05 15:06 (UTC)
milouse commented on 2017-09-05 09:23 (UTC) (edited on 2017-09-05 09:28 (UTC) by milouse)
oconnor663 commented on 2017-08-17 17:41 (UTC)
eschwartz commented on 2017-08-17 17:18 (UTC)
Redrield commented on 2017-08-17 17:14 (UTC)
Redrield commented on 2017-08-17 17:14 (UTC)
oconnor663 commented on 2017-08-02 17:37 (UTC)
eschwartz commented on 2017-08-02 17:28 (UTC)
oconnor663 commented on 2017-08-01 19:29 (UTC)
eschwartz commented on 2017-07-28 20:41 (UTC)
eschwartz commented on 2017-07-25 19:40 (UTC)
oconnor663 commented on 2017-07-25 19:28 (UTC) (edited on 2017-07-25 19:36 (UTC) by oconnor663)
eschwartz commented on 2017-07-25 19:04 (UTC)
oconnor663 commented on 2017-07-21 17:18 (UTC) (edited on 2017-07-21 18:11 (UTC) by oconnor663)
mpcsh commented on 2017-07-21 15:49 (UTC)
oconnor663 commented on 2017-07-20 04:44 (UTC)
dakra commented on 2017-07-20 02:48 (UTC)
oconnor663 commented on 2017-07-08 18:53 (UTC)
ShionRyuu commented on 2017-07-08 16:00 (UTC)
oconnor663 commented on 2017-02-21 19:57 (UTC)
dbrgn commented on 2017-02-21 09:11 (UTC)
oconnor663 commented on 2017-02-14 18:44 (UTC)
DriverChief commented on 2017-02-14 01:18 (UTC)
oconnor663 commented on 2017-02-08 23:07 (UTC)
ethanmad commented on 2017-02-08 21:53 (UTC) (edited on 2017-02-08 22:03 (UTC) by ethanmad)
oconnor663 commented on 2016-09-25 17:10 (UTC)
earfolds commented on 2016-09-24 18:29 (UTC)
chungy commented on 2016-06-29 22:05 (UTC)