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 .. 17 18 19 20 21 22 23 24 25 26 27 .. 32 Next › Last »

<deleted-account> commented on 2016-11-06 17:42 (UTC)

Anyone else having the problem that the "enable remote connections" button is not visible in chrome?

DaveB commented on 2016-08-16 23:26 (UTC)

@kcolford Added for next update.

kcolford commented on 2016-08-16 20:58 (UTC)

Could you add the -r option when groupadd is invoked? It seems a little silly to see gid 1001 being used by chrome-remote-desktop

DaveB commented on 2016-07-03 05:22 (UTC) (edited on 2016-07-03 05:23 (UTC) by DaveB)

Bztwy: Nope, I use XFCE on the host and client. Gnome looks problematic, someone else had problems with it.

Bztvuy commented on 2016-07-02 17:39 (UTC)

Have any of you managed to make it work with gnome 3? I've tried everything I've found about this online and the best I got was a black screen with an X in the middle that crashes after a few seconds.

mradi commented on 2016-05-10 14:17 (UTC)

These steps helped me, took me a while to figure out so here to record them Setup Steps: Install Chrome-remote-desktop 1. crd --setup 2. Enable chrome-remote-desktop from browser (and do crd --enable from command line while it is trying to set it up) 3. Optional: To get display 0 working https://productforums.google.com/forum/#!topic/chrome/LJgIh-IJ9Lk

DaveB commented on 2016-04-23 19:03 (UTC) (edited on 2016-08-17 00:23 (UTC) by DaveB)

@caleb You might have a good argument, but I still think that you can deal with the extra dependency of using nano than others dealing with vi. It's one thing to have to face an editor that is prehistoric to most users, it's another to expect them how to find out how to use it during a complex install, or interrupt the install to sort out the editor. ETA: Ok, if and when I get around to it (probably on the next update), I'll try and remember to include an option to select between nano and the default editor. But understand that I'm not putting a high priority on this. ETA2: Ok I've re-reconsidered, and the answer is still no. Nano is in the core, so it should be in any arch installation unless someone actually decides to uninstall it for whatever reason. Including it as a dependency is more of a fail-safe than anything. The argument as to what "anybody running arch" is a really big assumption on your part, or did you take a survey? It is possible to install and run arch without thinking about or needing to change the $EDITOR or $VISUAL variables on a permanent basis. "Knowing roughly what's going on" isn't enough to use vi, and certainly not while installing a complex piece of software. Adding an option to change the editor would add more unnecessary complexity. The only reason vi is the default editor in Arch or any other distro I know of is probably because it's POSIX standard, which has no relevance here at all and doesn't bind anyone else to anything. Most text installers including Linux distros themselves that require editing use something other than vi because vi is a pig to use if you don't already use it as your standard editor on a regular basis. The advantages of usability for more unsophisticated Arch users – and I've aimed this package so anyone can install it with a minimum of trouble, otherwise I wouldn't have bothered with the .install and CRD scripts – far outweigh any actual advantages there might be (I can't think of any) of effectively leaving it at vi. If you can provide any real benefits from using the $EDITOR/$VISUAL or real disadvantages in requiring nano, I'd be more than willing to reconsider. Until then, my decision to use nano is final.

alerque commented on 2016-04-23 12:21 (UTC)

@DaveB Please reconsider @dlh's request. I came here to request the same thing. Anybody running Arch is already going to have $EDITOR setup and at least one thing setup on their system. Yes this usually defaults to vi, but again anybody that setup Arch is going to know roughly what's going on. If they want to change that at the system level to another editor of their choosing they can, but forcing some other editor as a dependency for some package that has nomething to do with editing is not a good solution. Your preferences not agreeing with Arch's system defaults isn't enough reason to hoist that decision on all downstream users of a package.

DaveB commented on 2016-04-01 07:42 (UTC)

Unfortunately, there doesn't seem to be an i686 version anymore, getting a 404 error from the direct link and the download page. Will update as and when there is a 32-bit version available.

« First ‹ Previous 1 .. 17 18 19 20 21 22 23 24 25 26 27 .. 32 Next › Last »