Package Details: google-chrome 136.0.7103.113-1

Git Clone URL: https://aur.archlinux.org/google-chrome.git (read-only, click to copy)
Package Base: google-chrome
Description: The popular web browser by Google (Stable Channel)
Upstream URL: https://www.google.com/chrome
Keywords: chromium
Licenses: custom:chrome
Submitter: None
Maintainer: gromit
Last Packager: gromit
Votes: 2277
Popularity: 12.19
First Submitted: 2010-05-25 20:25 (UTC)
Last Updated: 2025-05-14 19:12 (UTC)

Dependencies (12)

Sources (3)

Pinned Comments

gromit commented on 2023-04-15 08:22 (UTC) (edited on 2023-05-08 21:42 (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 "Stable 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-stable" | \
     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 .. 23 24 25 26 27 28 29 30 31 32 Next › Last »

Det commented on 2013-01-26 20:36 (UTC)

I had that for a long time but then it just went away. It was caused by the history file getting corrupted. I'm assuming they fixed it but not those already corrupt files.

mityukov commented on 2013-01-26 20:20 (UTC)

It crashes few times a day when starting typing anything in the addressbar (live search is enabled). Does anyone else have this issue? Note: I haven't got it in Ubuntu, but I get it here, although it was updated two or three times already (so it's not certain-version-specific).

ruario commented on 2012-12-12 08:22 (UTC)

@codygman: No the URL scheme has not changed, the current (as I write this) latest build can be downloaded directly here with the version and revision numbers still present: http://dl.google.com/linux/chrome/rpm/stable/x86_64/google-chrome-stable-23.0.1271.97-171054.x86_64.rpm The URL you pointing to works like a symlink to the actual build.

<deleted-account> commented on 2012-12-12 03:32 (UTC)

url scheme changed.. new url: https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm

<deleted-account> commented on 2012-12-11 01:46 (UTC)

bad md5sums! I corrected it then I got another error: -> Extracting google-chrome-stable-23.0.1271.95-169798.x86_64.rpm with bsdtar ./opt/google/chrome/PepperFlash/libpepflashplayer.so: truncated bzip2 input

dejavu commented on 2012-12-06 12:59 (UTC)

@Qoru: Thanks, enabling the switch "Override software rendering list" did the trick. Seems that my nvidia card was blacklisted recently.

<deleted-account> commented on 2012-12-03 14:17 (UTC)

Is it possible the older versions of chrome can not be downloaded from dl.google.com any more ?

mike.cloaked commented on 2012-11-30 09:52 (UTC)

It works nicely for me for version 23.0.1271.95-1

mike.cloaked commented on 2012-11-29 21:22 (UTC)

Another new version released today (29th November 2012)

<deleted-account> commented on 2012-11-27 19:11 (UTC)

Qoru's solution worked with Nvidia for me.

Det commented on 2012-11-27 18:41 (UTC)

Not with me it is.

<deleted-account> commented on 2012-11-27 18:30 (UTC)

Flash videos are playing but sound is distorted in this version.

<deleted-account> commented on 2012-11-23 19:58 (UTC)

To solve the full screen issue: Go to chrome://flags, then enable "Override software rendering list". This worked for me with the radeon open source driver. Video is also much faster now. I also changed some other settings, like enable WebGL (works fine), etc., but the item mentioned above did it. It worked in Arch 32-bit and 64-bit for me. Other settings which may or may not be related: $ cat /etc/X11/xorg.conf.d/20-radeon.conf Section "Device" Identifier "Radeon" Driver "radeon" Option "AGPMode" "8" Option "ColorTiling" "on" Option "AccelMethod" "EXA" EndSection

dejavu commented on 2012-11-19 13:21 (UTC)

Sorry i meant 'software video rendering'. Previously I got 'accelerated video rendering' on my Nvidia card. On my ATI card, using the catalyst driver the acceleration works though. Independently the packager can't do anything about this. ;-)

dejavu commented on 2012-11-19 00:32 (UTC)

Flash doesn't work well in this release, using Nvidia card with proprietary driver. Now I have only 'software video decoding' instead of hardware (Youtube). Also the tab title isn't shown all the time.

Det commented on 2012-11-14 11:04 (UTC)

Like the Intel/Catalyst drivers or some special kernel.

Willrandship commented on 2012-11-14 07:26 (UTC)

Well, I can confirm that fullscreen flash IS working...so it's not a general problem. It's something on your end.

rumpelsepp commented on 2012-11-12 17:46 (UTC)

In addition to the problem with youtube videos, there is a problem with page titles on the tabs (html tag: <title>). For example a tab with opened Gmail only shows the favicon, but no text.

Det commented on 2012-11-10 19:08 (UTC)

Like f*ck it doesn't.

<deleted-account> commented on 2012-11-10 18:55 (UTC)

Confirmed, fullscreen flash video on youtube does not work with the latest update

stdigger commented on 2012-11-07 12:34 (UTC)

not work fullscreen flash video =(

Det commented on 2012-10-07 20:17 (UTC)

Yes :D. But it won't use it.

msx commented on 2012-09-26 00:13 (UTC)

I agree that in a public packages one should try to do things in a sane way whenever is posible but sometimes the only way to deal with real life problems is with ugly hacks (and they're lovely): it isn't bad at all to get your hands dirty sometimes... in fact it's very fun and hackish!

<deleted-account> commented on 2012-09-09 22:13 (UTC)

Thanks! I figured it was a horrible idea, but it made it work for now. I certainly don't recommend it. Why was it required in the first place? Is there a better solution?

Det commented on 2012-09-09 22:09 (UTC)

You have a worse judgment! >:O

<deleted-account> commented on 2012-09-09 22:07 (UTC)

Hello! Although a symlink was created for libudev.so.0 in /opt/google/chrome, I don't think chrome is looking for libraries there (perhaps you would have to set the "run in" or the like to that directory?) I put a sym link in /usr/lib against my better judgement to get it to work. Is there a better work around or did I mess something up on install?

Vrtak-CZ commented on 2012-08-14 23:45 (UTC)

http://dl.google.com/linux/chrome/rpm/stable/x86_64/google-chrome-stable-21.0.1180.79-151411.x86_64.rpm

Det commented on 2012-08-14 18:23 (UTC)

That's why I flagged it.

mike.cloaked commented on 2012-08-14 18:18 (UTC)

... yet another new version - .79 is out now.

ruario commented on 2012-08-14 10:44 (UTC)

@Det: Ok, well as I said I am not personally adverse to using the deb again if t3ddy wants to save some bandwidth for users of this PKGBUILD. I honestly thought that Google would have LZMA or XZ rpms available by now and as you know I suggested the format of rpms as they are more consistent with Arch conventions, making for a potentially easier to maintain PKGBUILD. I was *trying* to help, not inconvenience people. ;) Anyway, I suspect the bigger plus for t3ddy in switching to rpm was a predictable way to gather the ${_verbld} information for the meta script he uses to update the PKGBUILD. The command I supplied him previously did this. However, given that I now see that you can also query the APT repository to gather this information (as outlined in my previous post) I guess that advantage is moot. P.S. I guess I am lucky that my internet connection is fast enough that even with a 23% increase I can still download the rpms within a couple of seconds.

Det commented on 2012-08-14 10:01 (UTC)

Actually more than slightly. The 64-bit .77 rpm is 42.2MB, while the deb is only 32.3MB. That's a -23% difference.

ruario commented on 2012-08-14 07:55 (UTC)

@tancrackers: No it isn't 'optimised' for Ubuntu. The package contents of the rpm and deb files are identical apart from a different updater cron job file and 3 extra Debian specific files in the deb. You can confirm this as follows: $ mkdir rpm deb $ wget -qO- https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm | bsdtar -xf- -C rpm $ wget -qO- https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb | bsdtar -xOf- data.tar.* | bsdtar -xf- -C deb $ diff -qr rpm deb Files rpm/etc/cron.daily/google-chrome and deb/etc/cron.daily/google-chrome differ Only in deb/usr/share: applications Only in deb/usr/share: doc Only in deb/usr/share: menu I would imagine that Google build the binaries only once per architecture and then package them into to different formats (this is also what happens with Opera). @Det: If t3ddy wants to use the debs as a source, it is fine by me. I suggested the rpms as source because because they simplify the packaging steps, i.e. they are auto-unpacked by makepkg, they are more generic (less distro specific stuff to remove) and because at the time I felt it was easier to automate gathering the version and revision (${_verbld}) information, allowing for source URLs that reflect the actual build being packaged. As it happens I since discovered you can gather this information by parsing the APT repository meta-data. As you state however the deb files are slightly smaller, though I was hopeful that by now Google would have fixed this. There is nothing stopping them using LZMA/XZ compressed rpms as they can be handled by all their supported rpm-based distros (currently only Fedora and openSUSE). Anyway, for those wishing to manually update the PKGBUILD, you can work out the latest version and revision (${_verbld}) information (to update the URL) by reading it out of the first 96 bytes of data in the header of the rpm, like so: $ wget -qO- https://dl.google.com/linux/direct/google-chrome-stable_current_i386.rpm | head -c96 | strings | rev | awk -F"[:-]" '/emorhc/ { print $1 "-" $2 }' | rev 21.0.1180.77-150576 Alternatively you can pull it out of the YUM repository meta-data: $ wget -qO- https://dl.google.com/linux/chrome/rpm/stable/i386/repodata/other.xml.gz | gzip -d | awk -F\" '/-stable/ { print $10 "-" $12 }' 21.0.1180.77-150576 Or if you are using the .deb as a source from the APT repository meta-data: $ wget -qO- https://dl.google.com/linux/chrome/deb/dists/stable/main/binary-i386/Packages.gz | gzip -d | awk '/Package: google-chrome-stable/ { getline ; print $2 }' 21.0.1180.77-r150576 The format of the version specific URLs is as follows: https://dl.google.com/linux/chrome/rpm/stable/${_arch}/google-chrome-${_channel}-${_verbld}.${_arch}.rpm or https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-${_channel}/google-chrome-${_channel}_${_verbld}_${_arch}.deb

mike.cloaked commented on 2012-08-13 21:02 (UTC)

Seems that version 21.0.1180.77 was pushed out rather soon after the previous version!

Det commented on 2012-08-12 10:37 (UTC)

Naturally. Deb: http://pastebin.com/cP2rZPwm Rpm: http://pastebin.com/6329UEjW

antihero commented on 2012-08-12 09:57 (UTC)

Det do you have an up-to-date PKGBUILD I could use?

Det commented on 2012-08-12 09:55 (UTC)

Because the guy I had this discussion with felt .rpm's were more fit for Arch due to its lack of debianisms (the .menu and changelog.gz) even after it was revealed they use an inferior compression algorithm (Bzip2 vs LZMA). E: We originally used debs. I still do with my local package.

tancrackers commented on 2012-08-12 02:02 (UTC)

Why not use the .deb packages instead? Isn't chrome optimized mostly for Ubuntu anyways?

Det commented on 2012-08-11 16:17 (UTC)

Yeah, as already stated.

crimsonknave commented on 2012-08-11 14:57 (UTC)

DL URL that I could find that worked was https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm which worked with the checksum forbidden404 posted (for x86_64)

Det commented on 2012-08-09 16:36 (UTC)

It changes on every new build. That's just the general one to which I assume the latest one is linked to.

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