Package Details: keybase-git 5.6.0+36105.38f703e170-1

Git Clone URL: https://aur.archlinux.org/keybase-git.git (read-only, click to copy)
Package Base: keybase-git
Description: the Keybase Go client, filesystem, and GUI
Upstream URL: https://keybase.io
Licenses: BSD
Conflicts: kbfs, keybase, keybase-bin, keybase-gui, keybase-release
Provides: kbfs, keybase, keybase-gui
Submitter: oconnor663
Maintainer: keybase
Last Packager: oconnor663
Votes: 10
Popularity: 0.000000
First Submitted: 2016-02-10 22:48 (UTC)
Last Updated: 2020-09-21 16:43 (UTC)

Dependencies (10)

Required by (6)

Sources (1)

Latest Comments

1 2 3 4 5 Next › Last »

oconnor663 commented on 2020-09-21 16:44 (UTC)

@koumaza confirmed and just fixed. Thank you!

koumaza commented on 2020-09-20 19:53 (UTC)

Nice pkg. but, unzip required with dependence

oconnor663 commented on 2018-01-18 19:33 (UTC)

This package just got flagged as out-of-date, but as Eschwartz mentioned below, AUR policy says that VCS packages like this one shouldn't be updated unless there are changes in the actual packaging script.

Note: VCS packages are not considered out of date when the pkgver changes, do not flag them as the maintainer will merely unflag the package and ignore you. AUR maintainers should not commit mere pkgver bumps.

https://wiki.archlinux.org/index.php/Arch_User_Repository#Foo_in_the_AUR_is_outdated.3B_what_should_I_do.3F

oconnor663 commented on 2017-09-13 14:12 (UTC)

@swalladge it looks the update to yarn 1.0 uncovered this bug. We'll fix it upstream shortly. Thanks for reporting!

<deleted-account> commented on 2017-09-13 07:54 (UTC)

Installing this package results in ``` Couldn't parse yarn list to find electron: TypeError: Cannot read property '1' of null ``` :(

oconnor663 commented on 2017-07-27 15:03 (UTC)

I've disabled the daily version bumps, but it'll be a while before I have time to play with the Electron configuration. Community contributions welcome for this one :) [And we can make them the usual AUR way now, rather than needing to commit them upstream to get picked up in the Keybase build.]

oconnor663 commented on 2017-07-26 15:09 (UTC)

Thanks for experimenting with it, I'll take a shot at those changes when I adjust the build. Please pardon if changes don't roll out for a week or two. This isn't the primary package we direct people to (`keybase-bin` is), so breakage here wouldn't be the end of the world.

eschwartz commented on 2017-07-26 05:41 (UTC)

I, in turn, know very little about electron or node packaging. But I can say that my forked PKGBUILD runs: ``` mv opt/keybase/resources/app/ usr/share/keybase-app rm -rf opt/ ``` And then modifies run_keybase to execute `electron /usr/share/keybase-app` instead of `/opt/keybase/Keybase`. So far it seems to work okay. I know that the Arch maintainer for both electron and atom uses the system electron for atom, and while occasionally things do need to be patched to work okay with more recent versions of electron than upstream has tested, mostly it works. Using the system electron isn't a hard rule, it's just one of those things where it is very much preferable, and as I said, it seems to work based on my usage. That and the fact that more often than not things end up using the precompiled electron "just in case", without a firmly thought out policy of "new electron versions keep breaking our code, please don't use random system versions". The standard guidelines for packaging is that they should be built with system libs *where possible*, if that turns out to be impossible then you settle for what you *can* do. Or if you happen to know a lot about electron/nodejs and are faced with an uncooperative package, you can patch it and file pull requests upstream to make it legitimately work. That's what @tensor5 does for our [community]/atom package. :) ... Ideally I'd like some way to not have to download a prebuilt electron as part of the build process when assembling the app. If you happened to know how to do that, that would be great too...

oconnor663 commented on 2017-07-25 19:47 (UTC)

@Eschwartz thanks for pointing that out, I can disable version-only updates for this package. For the electron issue, I don't write much of our GUI code, but my (maybe out of date) understanding is that electron isn't stable enough for us to depend on a flexible version of it. Maybe changing the name of the package would be appropriate, if we need to keep using NPM's binaries?

eschwartz commented on 2017-07-25 19:27 (UTC)

Please stop pushing updates that only bump the pkgver, as this is against the AUR policy: https://wiki.archlinux.org/index.php/Arch_User_Repository#Foo_in_the_AUR_is_outdated.3B_what_do_I_do.3F An AUR package that builds from VCS sources should only ever be updated when the dependencies or build steps change, not just because there are new upstream commits. While an exception could be argued in the case of stable tagged releases, that isn't the case for most of the updates here... Also, as this is not a -bin package it should not use precompiled binaries but rather make use of the system electron package available in [community].

1 2 3 4 5 Next › Last »