Package Details: chrome-remote-desktop 130.0.6723.14-1

Git Clone URL: https://aur.archlinux.org/chrome-remote-desktop.git (read-only, click to copy)
Package Base: chrome-remote-desktop
Description: Access other computers or allow another user to access your computer securely over the Internet
Upstream URL: https://remotedesktop.google.com
Keywords: Chrome Chromium Google Networking Remote
Licenses: BSD
Submitter: None
Maintainer: frealgagu
Last Packager: frealgagu
Votes: 123
Popularity: 0.62
First Submitted: 2014-04-27 23:43 (UTC)
Last Updated: 2024-10-16 18:54 (UTC)

Pinned Comments

frealgagu commented on 2020-12-05 22:38 (UTC)

I maintain the latest built package at:

https://github.com/frealgagu/archlinux.chrome-remote-desktop/releases/

victorbrca commented on 2020-04-03 01:04 (UTC)

Thanks @frealgagu for packaging this, @nightuser for the existing session patch and @Brinsky for the instructions.

I've compiled both instructions with screenshots and added it to my blog if anyone is having issues with the install. Otherwise, just follow the instructions in the comments by @Brinsky from 2019-12-06 13:58.

Brinsky commented on 2019-12-06 13:58 (UTC)

Here's how I got this working with the new web app (remotedesktop.google.com):

  1. Build and install the package
  2. run crd --setup
  3. (Optional) Configure execution of your preferred window manager in ~/.chrome-remote-desktop-session
  4. Go to http://remotedesktop.google.com/headless
  5. Click "next" and "authorize" through each instruction
  6. Copy/paste and run the provided "Debian" command, which should look like the following: DISPLAY= /opt/google/chrome-remote-desktop/start-host --code="<UNIQUE_CODE>" --redirect-url="<https://remotedesktop.google.com/_/oauthredirect>" --name=
  7. Set up a name and PIN
  8. Wait for successful output containing "Host ready to receive connections."
  9. Run crd --start

Latest Comments

« First ‹ Previous 1 .. 22 23 24 25 26 27 28 29 30 31 32 Next › Last »

Binero commented on 2015-06-12 14:48 (UTC)

@DaveB Ideally the PKGBUILD would just get the version from the package. Anyway, I am trying to set this up with GDM/gnome-session, but having a bit of trouble. Do you happen to know how this is done? (not using lightdm)

DaveB commented on 2015-06-12 14:26 (UTC)

The current version I have installed is now 41.0.2272.41-1 $ ./chrome-remote-desktop --host-version 41.0.2272.41 At the time I wrote my PKBUILD (which is now out of date), the AUR version was still 38.xxx (if I remember right), and was throwing out-of-date warnings on guests. The current package seems up to date and checks out at the current version, but the version number stated in the PKGBUILD is old?

Binero commented on 2015-06-12 12:45 (UTC)

@DaveB How is this out of date? It always gets the latest one.

DaveB commented on 2015-03-28 14:55 (UTC)

Very out of date – current version is 40.0.2214.115. This is my PKGBUILD: pkgname=chrome-remote-desktop pkgver=40.0.2214.115 pkgrel=1 pkgdesc="Allows you to securely access your computer over the Internet through Chrome." url="https://chrome.google.com/webstore/detail/gbchcmhmhahfdphkhkmpfmihenigjmpp" arch=('i686' 'x86_64') license=('BSD') install=$pkgname.install depends=('python2' 'python2-psutil' 'gconf' 'gtk2' 'nss' 'xorg-xdpyinfo' 'xorg-setxkbmap' 'xorg-server-xvfb' 'xorg-xauth') source=("chrome-remote-desktop.service") md5sums=('cde1758e875ff114cc8153edb7087d2a') _arch=i386 if [ "$CARCH" == i686 ]; then md5sums+=('02963cacf89532849160df219676b05f') elif [ "$CARCH" == x86_64 ]; then _arch=amd64 md5sums+=('bbd835e485306b9be76c4d8555d5a6ea') fi source+=(${pkgname}_${pkgver}_$_arch.deb::https://dl.google.com/linux/direct/${pkgname}_current_$_arch.deb) package() { msg2 "Extracting data.tar.gz" bsdtar -xf data.tar.gz -C "$pkgdir/" msg2 "Patching Python script" sed -e '1 s/python/python2/' \ -e '/^.*sudo_command =/ s/"gksudo .*"/"pkexec"/' \ -e '/^.*command =/ s/s -- sh -c/s sh -c/' \ -i "$pkgdir"/opt/google/chrome-remote-desktop/chrome-remote-desktop msg2 "Removing things that won't work" rm -R "$pkgdir"/etc/cron.daily/ rm -R "$pkgdir"/etc/init.d/ rm -R "$pkgdir"/etc/pam.d/ msg2 "They forgot the LICENSE file, using the copyright file instead" install -Dm644 "$pkgdir"/usr/share/doc/$pkgname/copyright "$pkgdir"/usr/share/licenses/$pkgname/copyright msg2 "Adding a systemd user service" install -Dm644 "$srcdir"/$pkgname.service "$pkgdir"/usr/lib/systemd/user/$pkgname.service msg2 "Creating symlinks for chromium compatibility" mkdir -p "$pkgdir"/etc/chromium/native-messaging-hosts ln -sr "$pkgdir"/etc/opt/chrome/native-messaging-hosts/* "$pkgdir"/etc/chromium/native-messaging-hosts } I haven't tested the 386 version, but it should work.

WhiteHatHacker1 commented on 2015-03-13 18:06 (UTC)

I order to get my install working, I did what @mobabur94 typed (+1 for great instructions), but I had to do something a little different for the symlink. Because I already had another program that created the native-messaging-hosts directory, I couldn't link "/etc/opt/chrome/native-messaging-hosts/" to "/etc/chromium". Instead, I did this: "ln -s /etc/opt/chrome/native-messaging-hosts/* /etc/chromium/native-messaging-hosts/", in addition to deleting the link already there named "*".

mobabur94 commented on 2015-03-12 20:04 (UTC)

In order to get it working: 1. I manually created the chrome-remote-desktop group, and added myself to it. 2. I manually created the ~/.chrome-remote-desktop-session file with "exec startxfce4" in it. 3. I manually created the ~/.config/chrome-remote-desktop directory. 4. I manually changed the symlink for chromium using: "ln -s /etc/opt/chrome/native-messaging-hosts/ /etc/chromium" (@ishitatsuyuki is right) Also, I never used systemctl to start or enable the chrome-remote-desktop service; if I am not mistaken, the extension is supposed to invoke the python script. After all that, I was able to get it to show the "Enable remote connections" button. Clicking that button generates the host json file in ~/.config/chrome-remote-desktop. Now, connecting from another computer successfully starts xfce. But it starts it on :20, not :0, which I guess is expected, since the python script tries to get "a candidate display number for which there is currently no x server lock file". Although, it logs in using my user, chromium within the remote connection uses a blank profile, which gets created in ~/.config/chrome-remote-desktop/chrome-profile. I haven't tried to symlink that to ~/.config/chromium because the python script suggests to sign in and sync. I am not sure why remote assistance is allowed to use :0 while remote desktop needs to use :20... Perhaps package maintainer can fix the symlink and the groupadd.

« First ‹ Previous 1 .. 22 23 24 25 26 27 28 29 30 31 32 Next › Last »