Created attachment 558624 [details] keybase-bin-2.13.0_p20181219142726.ebuild Since the chances of getting Portage to properly build Electron apps seem slim, app-crypt/keybase does not include the GUI. This is a -bin package which pulls down the Debian release from upstream.
Notes for version 2.13.0_p20181219142726: GUI and CLI works. KBFS works, but mounts in the wrong place (/var/run/user/$UID/keybase/kbfs/). Firefox and Chrome/Chromium integration is not tested, and is currently not installed. Only tested on amd64, but should work on x86. This installs binary versions of all of Keybase, thus conflicting with app-crypt/keybase and app-crypt/kbfs. Would it be better to keep those packages and have just the GUI in a -bin package?
Created attachment 558666 [details] keybase-gui-bin-2.11.0_p20181204152506.ebuild For comparison, here's an alternative app-crypt/keybase-gui-bin that installs just the GUI, depending on the existing app-crypt/keybase and app-crypt/kbfs for the components that Portage can build from source. This is for an older version than keybase-bin above, to match the latest versions of keybase and kbfs currently in Portage.
I have no idea how to handle the version numbers properly. The source code has releases tagged in Git and published on GitHub: https://github.com/keybase/client/releases The official installation instructions at https://keybase.io/docs/the_app/install_linux say to download a version number-less package from https://prerelease.keybase.io/ , which I think tries to update itself. The list of available binary packages at https://s3.amazonaws.com/prerelease.keybase.io/linux_binaries/deb/index.html contains lots of files with the same version number, different time stamps, and different Git commit hashes. Crucially, none of the hashes match the one tagged in Git. E.g. version 2.11.0 of the source code was tagged at ec71fb1 on December 4, but there are no packages with that hash, and lots of packages with the same version but an earlier date.
(In reply to Karl-Johan Karlsson from comment #3) > I have no idea how to handle the version numbers properly. I am not particularly well-versed in how Debian does package repositories, but I took a look at the RPM repository for Fedora. It was no help whatsoever. The RPM repository contains exactly one package, which is the latest snapshot: as of this writing, 2.13.0.20181219142726.01e9fa19eb. They also ship a file in /etc/cron.daily/ which adds that repository to the system configuration (they can't do it in postinstall scripts, since by then the package manager is running and holding locks).
Created attachment 561934 [details] keybase-gui-bin-2.13.1_p20190115203650.ebuild Updated ebuild for app-crypt/keybase-gui-bin-2.13.1, to match app-crypt/keybase-2.13.1. Contains some new prebuild libraries and a changelog.
Created attachment 564412 [details] keybase-gui-bin-3.0.0_p20190205202117.ebuild Updated ebuild for app-crypt/keybase-gui-bin-3.0.0, to match app-crypt/keybase-3.0.0. No code changes.
When installing net-im/signal-desktop-bin-1.23.2, I ran into this problem: * Detected file collision(s): * * /usr/lib/debug/.build-id/47/02b4eaa1fddc415ebad5c22b5a1552d09f5661.debug * /usr/lib/debug/.build-id/47/02b4eaa1fddc415ebad5c22b5a1552d09f5661 * /usr/lib/debug/.build-id/f9/72b3718778c1061c1dd6a99c2bb8b62c42c545.debug * /usr/lib/debug/.build-id/f9/72b3718778c1061c1dd6a99c2bb8b62c42c545 Those are prebuilt libraries shipped with Electron: # ls -l /usr/lib/debug/.build-id/* /usr/lib/debug/.build-id/23: total 0 lrwxrwxrwx 1 root root 35 8 apr 11.42 0a1cc6287c539684f850259f8a2b8b4e9d7a55 -> //opt/keybase/swiftshader/libEGL.so lrwxrwxrwx 1 root root 46 8 apr 11.42 0a1cc6287c539684f850259f8a2b8b4e9d7a55.debug -> ../..//opt/keybase/swiftshader/libEGL.so.debug /usr/lib/debug/.build-id/47: total 0 lrwxrwxrwx 1 root root 34 8 apr 11.42 02b4eaa1fddc415ebad5c22b5a1552d09f5661 -> //opt/keybase/libVkICD_mock_icd.so lrwxrwxrwx 1 root root 45 8 apr 11.42 02b4eaa1fddc415ebad5c22b5a1552d09f5661.debug -> ../..//opt/keybase/libVkICD_mock_icd.so.debug /usr/lib/debug/.build-id/f9: total 0 lrwxrwxrwx 1 root root 38 8 apr 11.42 72b3718778c1061c1dd6a99c2bb8b62c42c545 -> //opt/keybase/swiftshader/libGLESv2.so lrwxrwxrwx 1 root root 49 8 apr 11.42 72b3718778c1061c1dd6a99c2bb8b62c42c545.debug -> ../..//opt/keybase/swiftshader/libGLESv2.so.debug Colliding build-ids in binary packages has happened before, e.g. in bug #593912, but without being resolved. For now, I installed both keybase-gui-bin and signal-desktop-bin with FEATURES="-splitdebug", which hides the problem. But does anyone know of a general solution?
Created attachment 589700 [details] keybase-bin-4.4.1_p20190910185008.ebuild Updated to latest version. Unlike keybase-bin-2.13.0_p20181219142726.ebuild installs everything which makes sense on Gentoo, including SUID binaries. Tested only amd64, everything works (including FUSE on /keybase). Use official run_keybase script to start/stop. I'd like to add extra validation using .sig file, but not sure how to do this - is there any examples in existing packages? Also I've plan to try to create non-binary package with GUI when I'll have spare time next time.
Well, not everything works out-of-box yet. I had to manually copy this file to make Firefox plugin works. cp /usr/lib/mozilla/native-messaging-hosts/io.keybase.kbnm.json ~/.mozilla/native-messaging-hosts/
Created attachment 590822 [details] keybase-gui-bin-4.4.2_p20190913172845.ebuild I no longer think that a keybase-bin package is the right way to go. We have app-crypt/keybase that builds the CLI applications from source. I would prefer just shipping the GUI in a -bin package, as long as Portage cannot build Electron apps from source. Here's an updated app-crypt/keybase-gui-bin-4.4.2, to match the recently updated app-crypt/keybase-4.4.2 in Portage.
(In reply to Karl-Johan Karlsson from comment #10) > as long as Portage cannot build Electron apps from source. BTW, why is this such a big issue? What makes Electron app that hard to build from source?
(In reply to Alex Efros from comment #11) > (In reply to Karl-Johan Karlsson from comment #10) > > as long as Portage cannot build Electron apps from source. > > BTW, why is this such a big issue? What makes Electron app that hard to > build from source? It's been quite a while since I checked, but as I remember there were two main obstacles: 1) The build system intermingles downloading, dependency resolution, and building, clashing with Portage's separation into distinct fetch/compile/install/package/merge steps. 2) NPM has a culture of providing ridiculously small packages. As I recall, a full build from source of the Keybase GUI ended up downloading well over a thousand NPM packages. 2a) If you want to just provide the entire dependency tree in a big tarball, you first need to convince NPM to give you one instead of assuming that everyone always has a live connection to GitHub, and then convince the Gentoo devs that such bundling is a good idea. 2b) If you want to handle dependencies properly, you need to have ebuilds for every NPM package in the dependency tree. At that scale, that absolutely requires tools for automatic translation, tools which did not exist.
(In reply to Karl-Johan Karlsson from comment #12) > (In reply to Alex Efros from comment #11) > 1) The build system intermingles downloading, dependency resolution, and > building, clashing with Portage's separation into distinct > fetch/compile/install/package/merge steps. Well, most Go apps do the same. Why this is a problem here and not there? > 2a) If you want to just provide the entire dependency tree in a big tarball, > you first need to convince NPM to give you one instead of assuming that > everyone always has a live connection to GitHub, and then convince the > Gentoo devs that such bundling is a good idea. Well, it's up to Gentoo devs to choose a way - provide extra archive with node_modules/ per package or let package download thousands deps while prepare/compile steps. > 2b) If you want to handle dependencies properly, you need to have ebuilds > for every NPM package in the dependency tree. At that scale, that absolutely > requires tools for automatic translation, tools which did not exist. This isn't an option. We already have this with Perl and g-cpan tool, and in my opinion this doesn't scale even this way, because dependencies of package or it dependencies changes too often and in most cases this means adding dozens of new dependencies with each package update.
Created attachment 591194 [details] keybase-gui-bin-4.5.0_p20190919193603.ebuild Updated app-crypt/keybase-gui-bin-4.5.0, to match the recently updated app-crypt/keybase-4.5.0 in Portage. Now calls xdg_desktop_database_update to handle .desktop file.
Created attachment 594984 [details] keybase-gui-bin-4.7.0_p20191021162721.ebuild Updated app-crypt/keybase-gui-bin-4.7.0, to match the recently updated app-crypt/keybase-4.7.0 in Portage.
Created attachment 596778 [details] keybase-gui-bin-4.7.2_p20191028173732.ebuild Updated app-crypt/keybase-gui-bin-4.7.2, to match the recently updated app-crypt/keybase-4.7.2 in Portage.
Created attachment 604122 [details] keybase-gui-bin-5.1.1_p20191211223501.ebuild Updated app-crypt/keybase-gui-bin-5.1.1, to match the recently updated app-crypt/keybase-5.1.1 in Portage.
I see that bug #703602 has also hit the Electron binary debug file collision from comment #7, and worked around it by using RESTRICT="splitdebug". I don't like that, but on the other hand it's what I've ended up doing manually anyway ("env FEATURES='-splitdebug' emerge keybase-gui-bin"), so maybe it would be easiest for everyone.
(In reply to Karl-Johan Karlsson from comment #17) > Created attachment 604122 [details] > keybase-gui-bin-5.1.1_p20191211223501.ebuild > > Updated app-crypt/keybase-gui-bin-5.1.1, to match the recently updated > app-crypt/keybase-5.1.1 in Portage. Hello, thank you for this ebuild. I am trying to install keybase on Gentoo, but I still can't run the GUI. I installed keybase-gui-bin from your ebuild, and got the keybase.desktop file, but when I try to run it I still get the same error message that I received before I installed keybase-gui-bin: > $ run_keybase > Starting via systemd... > Failed to restart keybase.gui.service: Unit keybase.gui.service not found. > Failed to launch GUI. Pass -g to prevent startup if on a machine without a graphical display. > run_keybase: Success! Do you have any idea about what I am doing wrong? Thank you!
(In reply to David Suarez from comment #19) > > Failed to restart keybase.gui.service: Unit keybase.gui.service not found. The ebuild only installs the parts I was able to test, and since I don't run systemd the unit files are not installed. I think it will work if you edit the function "src_prepare()" and replace the line rm -r usr/lib/ with these three lines: rm usr/lib/systemd/usr/kbfs.service rm usr/lib/systemd/usr/keybase-redirector.service rm usr/lib/systemd/usr/keybase.service Since those files should have been installed already by app-crypt/keybase. But, again, I cannot test this since I do not run systemd. In fact, I cannot test or develop this ebuild at all, since the cryptocurrency debacle and their acqusition by Zoom mean I don't trust them any more and therefore don't use the software. If anyone else would like to maintain this ebuild, feel free.
Created attachment 644522 [details] keybase-bin-5.5.1_p20200527202541.ebuild I don't trust Zoom too, but I don't think Zoom will be able to destroy Keybase security - at least, without being noticed, because such changes will require changes to Keybase protocols, most probably changes incompatible with current protocols - and current protocols doesn't require any trust to Keybase itself, so I believe it's okay to continue using Keybase, at least until we notice such changes. I don't use systemd, so this ebuild wasn't tested with systemd.
Adding a `app-crypt/keybase-gui-bin-6.0.2_p20220610191041.ebuild` to follow the current version in portage. It's based on the above 5.1.1 ebuild, only fixing the upstream filename/version. Not thoroughly tested, but no obvious problem after running it the GUI for half an hour.
Created attachment 866989 [details] keybase-gui-bin-6.0.2_p20220610191041.ebuild
