Package Details: google-chrome-dev 128.0.6559.0-1

Git Clone URL: https://aur.archlinux.org/google-chrome-dev.git (read-only, click to copy)
Package Base: google-chrome-dev
Description: The popular web browser by Google (Dev Channel)
Upstream URL: https://www.google.com/chrome
Keywords: chromium
Licenses: custom:chrome
Provides: google-chrome
Submitter: None
Maintainer: gromit
Last Packager: gromit
Votes: 649
Popularity: 0.33
First Submitted: 2009-06-05 21:02 (UTC)
Last Updated: 2024-06-27 21:11 (UTC)

Dependencies (12)

Required by (40)

Sources (3)

Pinned Comments

gromit commented on 2023-07-19 17:01 (UTC) (edited on 2023-07-19 17:02 (UTC) by gromit)

When reporting this package as outdated make sure there is indeed a new version for Linux Desktop. You can have a look at the "Dev updates" tag in Release blog for this.

You can also run this command to obtain the version string for the latest chrome version:

$ curl -sSf https://dl.google.com/linux/chrome/deb/dists/stable/main/binary-amd64/Packages | \
     grep -A1 "Package: google-chrome-unstable" | \
     awk '/Version/{print $2}' | \
     cut -d '-' -f1

Do not report updates for ChromeOS, Android or other platforms stable versions as updates here.

Latest Comments

« First ‹ Previous 1 .. 66 67 68 69 70 71 72 73 74 75 76 .. 91 Next › Last »

<deleted-account> commented on 2011-02-17 15:39 (UTC)

Ok, well I'm running it on 64 bit arch. That better?

sjakub commented on 2011-02-17 15:24 (UTC)

No it's not "64 bit version". It's both, depending on the architecture you make this package on.

<deleted-account> commented on 2011-02-17 15:18 (UTC)

It is the 64bit version.

Raymondcal commented on 2011-02-17 15:15 (UTC)

Hi ! Is this the 32 or 64bits version ?

<deleted-account> commented on 2011-02-03 05:18 (UTC)

Is anybody else getting a notification that the flash plug-in is blocked because it is out of date?

Det commented on 2011-01-21 21:28 (UTC)

@scio, that's why you weren't the one doing it :).

scio commented on 2011-01-21 19:51 (UTC)

@Det: sorry my mistake on the order, but the idea still stands. If another application is looking for .49 it will find (the now symlinked) .50. It's just not a good idea no matter which way you are doing it.

Det commented on 2011-01-21 18:52 (UTC)

@scio, I don't understand where did you get the idea that the symlink would point to the old version. It points from the _old_ one (.so.49) to the _new_ one (.so.50) and not the other way around. When and if the new Chrome is built for the new libavutil (.so.50) it will just read that one and never even know about the symlink.

Weegee commented on 2011-01-21 17:56 (UTC)

Problem solved! I just had to delete ~/.local/share/applications/google-chrome.desktop ... ^^'

scio commented on 2011-01-21 15:12 (UTC)

@Det: My advice the is opposite of being short-sighted, it is preventing future problems. Yes, it can be used short term to fix an upgrade problem like yours, but doing it for a package like this that is updated all the time seems like a bad idea. If he makes the symlink now and uses the browser for a day or two without problem he will most likely forget he made the symlink. The next version comes which actually uses the correct version, but you symlink points to the old one and segfault. This is a dev version of a browser, you should not be making symlinks of system libraries to make it work.