Package Details: chrome-remote-desktop 118.0.5993.9-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.56
First Submitted: 2014-04-27 23:43 (UTC)
Last Updated: 2023-10-06 21:11 (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 .. 24 25 26 27 28 29 30 31 32 Next › Last »

<deleted-account> commented on 2014-08-29 16:50 (UTC)

Disowned, feel free to adopt it if you are interested.

vendion commented on 2014-08-29 02:04 (UTC)

@jamesan: Following you're seven step procedure I get to 5 before I run into any problems. I have created ~/.config/chrome-remote-desktop and I have "/home/vendion/gocode/bin/wingo" (this is used by Slim to start my window manager) in my ~/.chrome-remote-desktop-session file. When I click "Enable Remote Connections" and give it a pin, I get an error and the json file is never created in ~/.config/chrome-remote-desktop. Any ideas?

<deleted-account> commented on 2014-08-28 17:19 (UTC)

I lost interest in chrome-remote-desktop and will disown it soon. Anybody interested in adopting it? Maybe jamesan?

<deleted-account> commented on 2014-08-17 23:40 (UTC)

@jamesan I am not sure if a pkgver() function would be useful for a non development package: It would work for anyone installing the package for the first time, but I think I would still need to submit new versions so AUR helpers could detect a update. Also, The google-chrome packages maintained by Det show a way to know the new version by checking the repository metadata. There probably should be a way to do the same for CRD.

jamesan commented on 2014-08-16 12:27 (UTC)

More progress! Using the pkgver function, you can extract the debian package version from it's control file with the one-liner: pkgver() { bsdtar -xf control.tar.gz -O control | grep '^Version: ' | cut -f2 -d' ' } Observing the various Chrome/Chromium AUR packages, packages that do determine the version simply skip the checksum verification (i.e. chromium-browser-bin) allowing the PKGBUILD to perpetually track the latest release without intervention. Modified the PKGBUILD slightly to do this here: http://pastebin.com/z6tCi28F (PKGBUILD) http://pastebin.com/2qJVBVpL (PKGBUILD diff)

<deleted-account> commented on 2014-08-16 11:57 (UTC)

@jamesan Thanks for pointing out the service error, I knew it should be under the Unit heading but I didn't pay too much attention when I was actually changing the file. The install file currently only tells the user to create ~/.config/chrome-remote-desktop, I will add something about the desktop session file.

jamesan commented on 2014-08-16 11:42 (UTC)

Perhaps we can add an install file that reminds the user to create a ~/.chrome-remote-desktop-session file and ~/.config/chrome-remote-desktop folder after installation and before enabling remote connections with the browser extension in order to get this working.

jamesan commented on 2014-08-16 11:40 (UTC)

The two condition lines in the systemd service unit file should go under the Unit heading, not the Service heading. Systemd complains it doesn't understand these lines under the Service heading and ignores them. ----- Also managed to resolve that problem where the systemd service unit would launch the X session which would immediately terminate. The user starting the service needs to have a file, ~/.chrome-remote-desktop-session, that contains a single line with the command launching the X session. For me using (SLiM/)XFCE4, that's simply startxfce4. Other suggestions include: - /etc/X11/Xsession - /usr/bin/openbox-session - /usr/bin/lxsession -s Lubuntu -e LXDE ----- The steps I took to get the whole thing running: 1. Install this AUR package. 2. Create the folder, ~/.config/chrome-remote-desktop 3. Create the file, ~/.chrome-remote-desktop-session, with the single line, "startxfce4" 4. Install the Chrome Remote Desktop extension to either Chrome or Chromium. 5. Launch the extension and "Enable Remote Connections" (this creates the host#...json file in ~/.config/chrome-remote-desktop) 6. Start and enable the chrome-remote-desktop systemd service. 7. Confirm the service successfully starts an X session and connect to this computer with another computer/phone/etc.

jamesan commented on 2014-08-16 09:59 (UTC)

I get the same error as muhas both when starting the systemd service unit and when starting it manually (/opt/google/chrome-remote-desktop/chrome-remote-desktop --start) while using SLiM/XFCE4. Not sure how to get passed this... I might test this on GDM/GNOME 3 if I get the time.