|
Description
Daniel Lin
2009-06-05 16:38:13 UTC
Created attachment 193642 [details]
www-client/google-chrome-bin-3.0.183.1-r17570.ebuild
I'm not sure since I normally don't create ebuilds, but shouldn't: SRC_URI="amd64? ( http://dl.google.com/linux/deb/pool/main/g/google-chrome-unstable/google-chrome-unstable_3.0.183.1-r17570_amd64.deb ) x86? ( http://dl.google.com/linux/deb/pool/main/g/google-chrome-unstable/google-chrome-unstable_3.0.183.1-r17570_i386.deb )" be SRC_URI="amd64? ( http://dl.google.com/linux/deb/pool/main/g/google-chrome-unstable/{P}_amd64.deb ) x86? ( http://dl.google.com/linux/deb/pool/main/g/google-chrome-unstable/{P}_i386.deb )" instead, to make the ebuild usable for future versions/releases? Good initiative anyway, chrome is a good browser. Acutally, it should be something like SRC_BASE="http://dl.google.com/linux/deb/pool/main/g/${PN%-bin}-unstable" SRC_URI="amd64? ( ${SRC_BASE}/${PN%-bin}-unstable_${PV}_amd64.deb ) x86? ( ${SRC_BASE}/${PN%-bin}-unstable_${PV}_i386.deb )" but in my excitement I forgot to fix up the URLs after copy'n'pasting :) It's hard to say how good it is when the Linux version is barely even usable, but it is something to look forward to. (In reply to comment #3) > SRC_URI="amd64? ( ${SRC_BASE}/${PN%-bin}-unstable_${PV}_amd64.deb ) > x86? ( ${SRC_BASE}/${PN%-bin}-unstable_${PV}_i386.deb )" That should be SRC_URI="amd64? ( ${SRC_BASE}/${PN%-bin}-unstable_${PVR}_amd64.deb ) x86? ( ${SRC_BASE}/${PN%-bin}-unstable_${PVR}_i386.deb )" Something is a little screwed up. Perhaps a fetch restriction should be applied to this. When letting portage download the .deb file, Google's servers appear to be looking at the user agent and returning a HTML page instead: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <title>CYBERUSE</title> </head> <body> <p align="center"> </p> <p align="center"> </p> <p align="center"><strong><a href="http://www.db2go.com/"><img src="/300x250.gif" border="0"></a> <a href="http://www.cyberuse.com"<img src="http://www.cyberuse.com/logo.gif" border="0" /></a> <a href="http://www.bestwebforms.com/"><img src="/b-300x250.gif" border="0"></a></strong></p> <p align="center"> </p> <p align="center"><strong><a href="http://www.cyberuse.com">www. CYBER USE .com</a></strong></p> <p align="center"> </p> <p align="center"><strong>We help strong resources to surmount server overloads by providing HTTP and FTP mirrors to their websites from ours. <br>Let us know if we can help you at: help@cyberuse.com</strong></p><br><br> <p align="center"><strong>Our other projects:</strong></p> <p align="center"><strong><a href="http://www.alltaste.com/">Bidding Directory</a> <a href="http://www.5starfiles.com/">5 Star Software Directory</a> <a href="http://www.webmastercatalog.com/">Webmaster Directory</a></strong></p> </body> </html> If anyone is considering making a -9999 ebuild, the most current release is available at: http://dl.google.com/linux/direct/google-chrome-unstable_current_i386.deb This ebuild also needs to depend on "app-arch/deb2targz" otherwise it will fail. If you get the following message: /opt/google/chrome/chrome: error while loading shared libraries: libnss3.so.1d: cannot open shared object file: No such file or directory Please read: http://code.google.com/p/chromium/issues/detail?id=13425 Created attachment 193775 [details] www-client/google-chrome-bin-3.0.183.1-r17570.ebuild Warning: I don't have an ARCH=x86 set up for Gentoo. With copies of 32-bit libgconf2.so.4+libORBit-2.so.0 (which are missing from emul-linux-x86-*), the browser runs and is surprisingly usable on ARCH=amd64. > Something is a little screwed up. Perhaps a fetch restriction should be applied > to this. When letting portage download the .deb file, Google's servers appear > to be looking at the user agent and returning a HTML page instead: "wget" on the URL works for me, and $FETCHCOMMAND should be wget by default. Do you have something else set in make.conf? > This ebuild also needs to depend on "app-arch/deb2targz" otherwise it will > fail. Portage will use "ar" to extract a .deb if "deb2targz" is not installed, which also works for me. > /opt/google/chrome/chrome: error while loading shared libraries: I screwed up a couple of the compatibility symlinks in the first ebuild. They should be correct out of the box now. (In reply to comment #9) > Created an attachment (id=193775) [edit] > www-client/google-chrome-bin-3.0.183.1-r17570.ebuild > > Warning: I don't have an ARCH=x86 set up for Gentoo. With copies of 32-bit > libgconf2.so.4+libORBit-2.so.0 (which are missing from emul-linux-x86-*), the > browser runs and is surprisingly usable on ARCH=amd64. > > > Something is a little screwed up. Perhaps a fetch restriction should be applied > > to this. When letting portage download the .deb file, Google's servers appear > > to be looking at the user agent and returning a HTML page instead: > No strange $FETCHCOMMAND setup. I do have FEATURES="parallel-fetch" in /etc/make.conf which is the only thing I can think of that would affect how wget works with respect to portage. > "wget" on the URL works for me, and $FETCHCOMMAND should be wget by default. > Do you have something else set in make.conf? > > > This ebuild also needs to depend on "app-arch/deb2targz" otherwise it will > > fail. > > Portage will use "ar" to extract a .deb if "deb2targz" is not installed, which > also works for me. > > > /opt/google/chrome/chrome: error while loading shared libraries: > > I screwed up a couple of the compatibility symlinks in the first ebuild. They > should be correct out of the box now. > Created attachment 194211 [details] www-client/google-chrome-bin-3.0.187.0-r18043.ebuild Version bump, and added a HORRIBLE HORRIBLE HACK to get a copy of 32-bit libgconf-2.so.4. This is only a workaround to enable ~amd64 and should not be committed to any tree: fixing bug 258066 would be the right thing to do. (In reply to comment #11) > Created an attachment (id=194211) [edit] > www-client/google-chrome-bin-3.0.187.0-r18043.ebuild $ google-chrome /opt/google/chrome/chrome: error while loading shared libraries: libnss3.so.1d: cannot open shared object file: No such file or directory it's due to error on 77 line of ebuild: ${CHROME_HOME}/lib32/${i##*/} instead of ${CHROME_HOME}/lib32/${i##*/}.1d Created attachment 194580 [details] www-client/google-chrome-bin-3.0.187.0-r18043.ebuild > $ google-chrome > /opt/google/chrome/chrome: error while loading shared libraries: > > it's due to error on 77 line of ebuild: > ${CHROME_HOME}/lib32/${i##*/} instead of ${CHROME_HOME}/lib32/${i##*/}.1d D'oh, that's what happens when I don't have a x86 machine to test on. Just remove the .1d and it should be fine? (In reply to comment #13) > D'oh, that's what happens when I don't have a x86 machine to test on. Just > remove the .1d and it should be fine? > There still seems to be cairo related issues: # google-chrome ... /opt/google/chrome/chrome: symbol lookup error: /opt/google/chrome/chrome: undefined symbol: cairo_format_stride_for_width ... Segmentation fault Cairo version: x11-libs/cairo-1.8.6-r1 USE="X opengl svg -cleartype -debug -directfb -doc -glitz -xcb" (In reply to comment #14) > (In reply to comment #13) > > D'oh, that's what happens when I don't have a x86 machine to test on. Just > > remove the .1d and it should be fine? > > > > There still seems to be cairo related issues: > > # google-chrome > ... > /opt/google/chrome/chrome: symbol lookup error: /opt/google/chrome/chrome: > undefined symbol: cairo_format_stride_for_width > ... > Segmentation fault > > Cairo version: > x11-libs/cairo-1.8.6-r1 USE="X opengl svg -cleartype -debug -directfb -doc > -glitz -xcb" > Sorry - my mistake (this is AMD64 so it's emul-linux-x86-gtklibs). As such, I think you also need AMD64 depends on >=app-emulation/emul-linux-x86-gtklibs-20081109. The unmasked versions exhibit the segfault above. Created attachment 195116 [details]
www-client/google-chrome-bin-3.0.189.0-r18569.ebuild
Version bump.
Google has started creating lzma-compressed debs, so DEPEND=app-arch/lzma-utils was added.
Version bump to 3.0.190.2-r19048 works for me with just a rename of the last ebuild. Created attachment 196328 [details]
www-client/google-chrome-bin-9999.ebuild
ebuild is based on google-chrome-bin-3.0.189.0-r18569.ebuild
(In reply to comment #18) > Created an attachment (id=196328) [edit] > google chrome current (unstable) ebuild > > ebuild is based on google-chrome-bin-3.0.189.0-r18569.ebuild > I'm guessing that you haven't actually tried that on amd64. It'll fail to install... In any case, I don't see the reason behind making an -scm/-9999 ebuild when upstream has a perfectly good versioning scheme? You can check for the latest version -- without having to download an entire .deb -- at http://dl.google.com/linux/deb/dists/stable/main/binary-{i386,amd64}/Packages > I'm guessing that you haven't actually tried that on amd64. It'll fail to > install... yes, i haven't tried on amd64 - I guess that your ebuild is correct and difference between version based and current version is only in downloading. > > In any case, I don't see the reason behind making an -scm/-9999 ebuild when > upstream has a perfectly good versioning scheme? You can check for the latest > version -- without having to download an entire .deb -- at > http://dl.google.com/linux/deb/dists/stable/main/binary-{i386,amd64}/Packages The reason is quite simple - try to test current version i.g. for test purposes, on other side - people want to have 9999 ebuild - i.g. Brian Johnson - I guess that he isn't alone. Maybe merge to ebuild into one ? if ebuild name contains X.Y.Z-rQQQQQ - it's a versioned build, if 9999 it's a currect unstable build (In reply to comment #20) > > I'm guessing that you haven't actually tried that on amd64. It'll fail to > > install... > yes, i haven't tried on amd64 - I guess that your ebuild is correct and > difference between version based and current version is only in downloading. Indeed. On amd64, as a workaround for bug #258066, extra .debs are fetched. > > In any case, I don't see the reason behind making an -scm/-9999 ebuild when > > upstream has a perfectly good versioning scheme? You can check for the latest > > version -- without having to download an entire .deb -- at > > http://dl.google.com/linux/deb/dists/stable/main/binary-{i386,amd64}/Packages > The reason is quite simple - try to test current version i.g. for test > purposes, on other side - people want to have 9999 ebuild - i.g. Brian Johnson > - I guess that he isn't alone. > > Maybe merge to ebuild into one ? if ebuild name contains X.Y.Z-rQQQQQ - it's a > versioned build, if 9999 it's a currect unstable build The _unstable_current.deb on their download server is just a symlink to the latest _X.Y.Z-rQQQQQ.deb -- there is absolutely no difference between what's installed with a -3.0.190.2-r19048.ebuild versus a -9999.ebuild right now. When a new version comes out, wouldn't it be much better to tell Portage that there's a new 3.0.???-r????? version, instead of manually re-installing 9999? Version bump to 3.0.191.3-r19935 works without any modifications from my last ebuild. Version bump to 3.0.192.0-r19969 works without any modifications from my last ebuild. (In reply to comment #19) > In any case, I don't see the reason behind making an -scm/-9999 ebuild when > upstream has a perfectly good versioning scheme? You can check for the latest > version -- without having to download an entire .deb -- at > http://dl.google.com/linux/deb/dists/stable/main/binary-{i386,amd64}/Packages The Chrome folks have been pushing a new version about every 1-2 weeks. Is someone going to bump the ebuild version every time? I for one would always want the latest version. (In reply to comment #24) > The Chrome folks have been pushing a new version about every 1-2 weeks. Is > someone going to bump the ebuild version every time? I for one would always > want the latest version. Dunno about what users think, but I think consensus among devs is that live ebuilds are untestable. You'd much rather have a dev bump the version and re-test, than have give out a live ebuild which may randomly break in the future. I'm planning to do good packaging work for this in the next few weeks. 3.0.194.0-r20577 is out but fails to load *any* pages on my amd64 machine. Plain x86 users may have better luck? Preferences, tab manipulation, and theming have moved forward in the new release. (In reply to comment #27) > 3.0.194.0-r20577 is out but fails to load *any* pages on my amd64 machine. > Plain x86 users may have better luck? Preferences, tab manipulation, and > theming have moved forward in the new release. > I'm seeing the same thing. 3.0.192 also did this for me. It gives an immediate DNS resolution error. Navigating by IP address seems to work just fine. (In reply to comment #27) > 3.0.194.0-r20577 is out but fails to load *any* pages on my amd64 machine. http://code.google.com/p/chromium/issues/detail?id=16815 Workaround: rm /opt/google/chrome/chrome-sandbox Should be fixed in the next version. I submitted www-client/chromium ebuild (which compiles Chromium from source) as https://bugs.gentoo.org/show_bug.cgi?id=278975 . The source tarball is not yet published, but I hope to get the ebuild reviewed by the time tarball appears. google-chrome-bin-9999.ebuild seems to not be able to unpack or find libgconf for amd64. google-chrome-bin-3.0.189.0-r18569.ebuild can't find the .deb file. I was able to install a working chrome on ~amd64 by renaming the latest .deb file to what google-chrome-bin-3.0.189.0-r18569.ebuild expects. (In reply to comment #31) > google-chrome-bin-9999.ebuild seems to not be able to unpack or find libgconf > for amd64. > google-chrome-bin-3.0.189.0-r18569.ebuild can't find the .deb file. > > I was able to install a working chrome on ~amd64 by renaming the latest .deb > file to what google-chrome-bin-3.0.189.0-r18569.ebuild expects. > Yeah, the -9999 ebuild is broken. To install 3.0.195.1-r21222, just rename the ebuild to match. Created attachment 200621 [details] www-client/google-chrome-bin-3.0.197.11-r22553.ebuild Bug #278975 would be better, but until the multilib situation on amd64 improves, this hack works... (In reply to comment #33) > Created an attachment (id=200621) [edit] > www-client/google-chrome-bin-3.0.197.11-r22553.ebuild > > Bug #278975 would be better, but until the multilib situation on amd64 > improves, this hack works... > This ebuild is broken. USE dependencies require EAPI=2. New version is out - 3.0.198.1-r23116 - a simple rename works (also had to add EAPI="2" I also think the ebuild should either add these to the start up script or tell the users about these --enable-plugins --enable-greasemonkey --enable-user-scripts --enable-extensions also /opt/google/chrom/plugins should either symlink to , or should symlink to the items in /usr/lib32/nsbrowser/plugins/ Doing those two things allows flash to work (though only --enable-plugins is needed for flash to work) Created attachment 201732 [details]
www-client/google-chrome-bin-3.0.198.1-r23116.ebuild
Works for me although I had to "emerge -C deb2targz". Otherwise unpack() tries to use deb2targz to extract the .deb files, which promptly fails as they have an lzma inside (data.tar.lzma). deb2targz doesn't work so well with lzma files in a .deb (but fortunately unpack() will fall back to using "ar" to extract the .deb). i am getting this error with the latest ebuild: !!! Couldn't download 'google-chrome-unstable_3.0.198.1-r23116_i386.deb'. Aborting. !!! Fetch failed for google-chrome-unstable_3.0.198.1-r23116_i386.deb, can't update Manifest (In reply to comment #38) > i am getting this error with the latest ebuild: > !!! Couldn't download 'google-chrome-unstable_3.0.198.1-r23116_i386.deb'. > Aborting. > !!! Fetch failed for google-chrome-unstable_3.0.198.1-r23116_i386.deb, can't > update Manifest > I think this is because they took it down, since a new release is out - 4.0.202.2-r23795 I haven't verified it yet. You can check for the latest package at http://dl.google.com/linux/deb/dists/stable/main/binary-amd64/Packages (replace amd64 with i386 to get info on it. another good feed to follow http://googlechromereleases.blogspot.com/ sorry for the spam :/ Created attachment 201886 [details]
google-chrome-bin-9999.ebuild
i got this to work. its based on the latest one, i just modified the src_uri and it worked. Any idea on how to get it to always fetch the sources? Is there a live.eclass yet or is it just a proposal still?
(In reply to comment #42) > Created an attachment (id=201886) [edit] > google-chrome-bin-9999.ebuild > > i got this to work. its based on the latest one, i just modified the src_uri > and it worked. Any idea on how to get it to always fetch the sources? Is > there a live.eclass yet or is it just a proposal still? > The .deb files from http://dl.google.com/linux/direct/ are missing, why not write it with good old: src_unpack() { LV=`curl --silent http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/LATEST` elog "Installing/updating to version ${LV}" wget -c "http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/${LV}/chrome-linux.zip" -O "${T}"/${PN}-${LV}.zip unzip -qo "${T}"/${PN}-${LV}.zip || die "Unpack failed" chmod -fR a+rX,u+w,g-w,o-w chrome-linux/ } where are used the snapshots of buildbot, instead of debian packages? Because this ebuild makes use of the gconf and orbit2 binary from debian, and the google repo is for debian, so they can work well together. (In reply to comment #43) > (In reply to comment #42) > > Created an attachment (id=201886) [edit] > > google-chrome-bin-9999.ebuild > > > > i got this to work. its based on the latest one, i just modified the src_uri > > and it worked. Any idea on how to get it to always fetch the sources? Is > > there a live.eclass yet or is it just a proposal still? > > > > The .deb files from http://dl.google.com/linux/direct/ are missing, why not > write it with good old: > > src_unpack() { > LV=`curl --silent > http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/LATEST` > elog "Installing/updating to version ${LV}" > wget -c > "http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/${LV}/chrome-linux.zip" > -O "${T}"/${PN}-${LV}.zip > unzip -qo "${T}"/${PN}-${LV}.zip || die "Unpack failed" > chmod -fR a+rX,u+w,g-w,o-w chrome-linux/ > } > > where are used the snapshots of buildbot, instead of debian packages? > Okay, but this google repo for debian is kind of...missing? (In reply to comment #44) > Because this ebuild makes use of the gconf and orbit2 binary from debian, and > the google repo is for debian, so they can work well together. > > (In reply to comment #43) > > (In reply to comment #42) > > > Created an attachment (id=201886) [edit] > > > google-chrome-bin-9999.ebuild > > > > > > i got this to work. its based on the latest one, i just modified the src_uri > > > and it worked. Any idea on how to get it to always fetch the sources? Is > > > there a live.eclass yet or is it just a proposal still? > > > > > > > The .deb files from http://dl.google.com/linux/direct/ are missing, why not > > write it with good old: > > > > src_unpack() { > > LV=`curl --silent > > http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/LATEST` > > elog "Installing/updating to version ${LV}" > > wget -c > > "http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/${LV}/chrome-linux.zip" > > -O "${T}"/${PN}-${LV}.zip > > unzip -qo "${T}"/${PN}-${LV}.zip || die "Unpack failed" > > chmod -fR a+rX,u+w,g-w,o-w chrome-linux/ > > } > > > > where are used the snapshots of buildbot, instead of debian packages? > > > Created attachment 202637 [details]
www-client/google-chrome-bin-4.0.203.2-r24690.ebuild
A big jump in version numbers, and it's a true 64-bit executable on amd64 now!
(In reply to comment #46) > Created an attachment (id=202637) [edit] > www-client/google-chrome-bin-4.0.203.2-r24690.ebuild > > A big jump in version numbers, and it's a true 64-bit executable on amd64 now! > Thanks for the work. Here are a few things I spotted, however. > src_install() { > cd "${D}" > > lzma -cd ${WORKDIR}/${MY_PN}.tar.lzma | tar xvf - || die "Couldn't extract" Shouldn't this be handled in src_unpack? Also, shouldn't you be unpacking to WORKDIR, then in src_install using cp/do* to move everything to D? > rm -r etc usr/bin/google-chrome [...] > cat <<-EOF >"${T}/google-chrome" > #!/bin/sh > exec /${CHROME_HOME}/google-chrome --enable-plugins \ > --enable-greasemonkey --enable-user-scripts --enable-extensions \ > "\$@" > EOF > dobin "${T}/google-chrome" This is a bad idea, imo. You're forcing others to use known buggy features they may not want enabled. Also, you don't set LD_LIBRARY_PATH so it will pick up the symlinks for nss, nspr, etc like the default wrapper does. > sed "s:Exec=/.*/:Exec=:" \ > ${CHROME_HOME}/google-chrome.desktop > "${T}/google-chrome.desktop" Haven't tested, but isn't this a sandbox violation? Perhaps you meant ${D}/${CHROME_HOME} ? Also, quotes around paths with variables (more than just here). Nevermind on that last comment about sandbox violation. I thought CHROME_HOME started with /opt Oops. (In reply to comment #47) > (In reply to comment #46) > > rm -r etc usr/bin/google-chrome > [...] > > cat <<-EOF >"${T}/google-chrome" > > #!/bin/sh > > exec /${CHROME_HOME}/google-chrome --enable-plugins \ > > --enable-greasemonkey --enable-user-scripts --enable-extensions \ > > "\$@" > > EOF > > dobin "${T}/google-chrome" > > This is a bad idea, imo. You're forcing others to use known buggy features they > may not want enabled. Also, you don't set LD_LIBRARY_PATH so it will pick up > the symlinks for nss, nspr, etc like the default wrapper does. coderoar's ebuild includes something like this, but the menu entry would still launch the original without arguments; I just fixed that up. I agree that secretly enabling these experimental features is a good idea either, but it they do seem much more stable than in earlier releases... BTW, the paths are set up correctly, because this script wraps the original wrapper script, not the binary directly. (In reply to comment #49) > launch the original without arguments; I just fixed that up. I agree that > secretly enabling these experimental features is a good idea either, but it That's a confusing sentence; it should read more like "isn't such a good idea". Ever since portage went to the 4.0 builds (3.0 disappeared altogether), chromium no longer runs and produces a segfault. The 9999 ebuild assumes that the version number for x86 and amd64 are the same, but they're not always:
fix is to move the amd64 check to before grabbing the LATEST file, and include the arch when you grab the file.
diff -u chromium-bin-9999.ebuild~ chromium-bin-9999.ebuild
--- chromium-bin-9999.ebuild~ 2009-08-29 15:38:52.000000000 -0700
+++ chromium-bin-9999.ebuild 2009-09-03 14:23:11.525062654 -0700
@@ -33,11 +33,11 @@
opt/chromium.org/chrome-linux/libavutil.so.50"
src_unpack() {
- LV=`curl --silent http://build.chromium.org/buildbot/snapshots/chromium-rel-linux/LATEST`
- elog "Installing/updating to version ${LV}"
if use amd64; then
arch_path="-64"
fi
+ LV=`curl --silent http://build.chromium.org/buildbot/snapshots/chromium-rel-linux${arch_path}/LATEST`
+ elog "Installing/updating to version ${LV}"
wget -c "http://build.chromium.org/buildbot/snapshots/chromium-rel-linux${arch_path}/${LV}/chrome-linux.zip" -O "${T}"/${PN}-${LV}.zip
unzip -qo "${T}"/${PN}-${LV}.zip || die "Unpack failed"
chmod -fR a+rX,u+w,g-w,o-w chrome-linux/
Created attachment 203365 [details]
www-client/google-chrome-bin-4.0.206.0-r25285.ebuild
Created attachment 204067 [details]
www-client/google-chrome-bin-4.0.207.0-r25617
(In reply to comment #54) > Created an attachment (id=204067) [edit] > www-client/google-chrome-bin-4.0.207.0-r25617 > depend on gnome-base/gconf Created attachment 204555 [details]
www-client/google-chrome-bin-4.0.211.2-r26474
Added gnome-base/gconf
thx : it works fine. Tested here: Working as inteded. Better than chromium-bin. Rodrigo, could you describe what's better? That would help improving chromium-bin. Created attachment 205192 [details]
www-client/google-chrome-bin-4.0.213.1-r27053
Your ebuils fails if deb2targz is installed: deb2targz: converting 'google-chrome-unstable_4.0.213.1-r27053_amd64.deb' ... deb2targz: skipping section 'debian-binary' deb2targz: skipping section 'control.tar.gz' deb2targz: skipping section 'data.tar.lzma' mv: cannot stat `google-chrome-unstable_4.0.213.1-r27053_amd64.tar.gz': No such file or directory Created attachment 205253 [details, diff] www-client/google-chrome-bin-4.0.213.1-r27053.ebuild.patch (In reply to comment #37) > Works for me although I had to "emerge -C deb2targz". > > Otherwise unpack() tries to use deb2targz to extract the .deb files, which > promptly fails as they have an lzma inside (data.tar.lzma). deb2targz doesn't > work so well with lzma files in a .deb (but fortunately unpack() will fall back > to using "ar" to extract the .deb). > So using ar instead of deb2targz can avoid this. Created attachment 205893 [details]
www-client/google-chrome-bin-4.0.220.1_p27713.ebuild
Created attachment 206930 [details]
ebuild for google chrome current unstable
I update this ebuild to download current unstable version of this powerful browser for linux, hope this help people trying to find out how to install chrome on gentoo linux :)
I think this ebuild needs some kind of warning about having /dev/shm mounted properly. I had the mount point commented out and Chrome would start, but pages wouldn't load and Bug Buddy popped up and killed it. An error message in the console seemed to suggest the error was related to /dev/shm, so I added the mount point and everything worked great. (In reply to comment #65) > I think this ebuild needs some kind of warning about having /dev/shm mounted > properly. I had the mount point commented out and Chrome would start, but > pages wouldn't load and Bug Buddy popped up and killed it. An error message in > the console seemed to suggest the error was related to /dev/shm, so I added the > mount point and everything worked great. POSIX mandates /dev/shm. If you don't have it, you've broken far more than just Chrome -- parts of glibc's SysV IPC support require it, for example. A non-mounted /dev/shm should not be supported in any way. This is the first package that's had any problems... http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=8 If it is as absolutely critical as you say, however, then the Handbook needs to be changed to highlight this. (In reply to comment #67) > This is the first package that's had any problems... > > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=8 > > If it is as absolutely critical as you say, however, then the Handbook needs to > be changed to highlight this. To correct my earlier statement: http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt says that SysV IPC doesn't need /dev/shm, but POSIX shared memory does. You'll have a partly broken system if you forget to mount /proc and /sys, too, and the handbook doesn't say anything about those either. Although actually, I wonder what version of baselayout you're running; OpenRC unconditionally mounts /dev/shm whether or not it's in fstab, and I was under the impression that baselayout-1 did too unless you explicitly told it not to. I'm running sys-apps/baselayout-1.12.11.1 on the system in question. /proc and /sys were automatically mounted for me, both here, and on every other Gentoo system I'm running. (In reply to comment #64) > Created an attachment (id=206930) [details] > ebuild for google chrome current unstable > > I update this ebuild to download current unstable version of this powerful > browser for linux, hope this help people trying to find out how to install > chrome on gentoo linux :) This ebuild should have a mechanism for allowing a new binary to be downloaded/emerged each time. When there's a new unstable release the filesize and -- obviously -- the hashes of the file change, with which the ebuild does not deal in any way, but just failes colourfully. Hi, the google-chrome-bin-4.0.220.1_p27713.ebuild no longer works and just gives me an error >>> Downloading 'http://dl.google.com/linux/deb/pool/main/g/google-chrome-unstable/google-chrome-unstable_4.0.220.1-r27713_amd64.deb' --2009-10-27 00:33:58-- http://dl.google.com/linux/deb/pool/main/g/google-chrome-unstable/google-chrome-unstable_4.0.220.1-r27713_amd64.deb Resolving dl.google.com... 74.125.39.93, 74.125.39.91, 74.125.39.190, ... Connecting to dl.google.com|74.125.39.93|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2009-10-27 00:33:58 ERROR 404: Not Found. This Link is wrong and the file is not mirrored over distfiles >>> Downloading 'http://nash.fs.lmu.de/gentoo/distfiles/google-chrome-unstable_4.0.220.1-r27713_amd64.deb' Michael Correct, there was a new release, they remove the old one as soon as the new one is released. Just rename the ebuild to google-chrome-bin-4.0.223.11-r29916.ebuild and then run ebuild google-chrome-bin-4.0.223.11-r29916.ebuild manifest then emerge i got a QA notice for the latest unstable Aborting due to QA concerns: textrels: * QA Notice: Pre-stripped files found: * /opt/google/chrome/libavcodec.so.52 * /opt/google/chrome/libavformat.so.52 * /opt/google/chrome/libavutil.so.50 ecompressdir: bzip2 -9 /usr/share/man * QA Notice: The following files contain runtime text relocations * Text relocations force the dynamic linker to perform extra * work at startup, waste system resources, and may pose a security * risk. On some architectures, the code may not even function * properly, if at all. * For more information, see http://hardened.gentoo.org/pic-fix-guide.xml * Please include the following list of files in your report: * TEXTREL opt/google/chrome/libavcodec.so.52 Created attachment 209314 [details]
www-client/google-chrome-bin-4.0.223.11.ebuild
http://www.google.com/chrome/intl/en/w00t.html It's officially a Beta now. Doesn't this mean it can and should go into the default repository as ~x86 ? (In reply to comment #74) > Created an attachment (id=209314) [details] > www-client/google-chrome-bin-4.0.223.11.ebuild > This build works great on my AMD Phenom64 XII quad-core PC, and I'm installing it on my AMD Turion64 x2 dual-core laptop atm. Both running Sabayon 5. Just added this ebuild to my local overlay and emerged. No problems while emerging but running is getting me this error: eli@llama ~ $ google-chrome /opt/google/chrome/google-chrome: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /opt/google/chrome/google-chrome) I am guess that the latest version of gcc does not support the C++ v3.4.9 ABI. Is there something I can do? I just tried google-chrome-bin-9999.ebuild. Install went fine, but running fails to find man library dependency. Error: usr/bin/google-chrome: error while loading shared libraries: libnss3.so.1d: cannot open shared object file: No such file or directory Not sure how to modify the ebuild for this, ... but I needed to install: dev-libs/nss-3.12.3-r1 and dev-libs/nspr-4.8, followed by making the following links: --to dev-libs/nss libs------------------------------------------------------ ln -s /usr/lib/nss/libnss3.so /usr/lib/nss/libnss3.so.1d ln -s /usr/lib/nss/libnssutil3.so.12 /usr/lib/libnssutil3.so.1d ln -s /usr/lib/nss/libsmime3.so.12 /usr/lib/libsmime3.so.1d ln -s /usr/lib/nss/libssl3.so.12 /usr/lib/libssl3.so.1d ln -s /usr/lib/nss/libnss3.so.1d /usr/lib/libnss3.so.1d --to dev-libs/nspr libs------------------------------------------------------ ln -s /usr/lib/nspr/libplds4.so /usr/lib/libplds4.so.0d ln -s /usr/lib/nspr/libplc4.so /usr/lib/libplc4.so.0d ln -s /usr/lib/nspr/libnspr4.so /usr/lib/libnspr4.so.0d after this it runs (In reply to comment #78) > I just tried google-chrome-bin-9999.ebuild. Install went fine, but running > fails to find man library dependency. > Error: > usr/bin/google-chrome: error while loading shared libraries: libnss3.so.1d: > cannot open shared object file: No such file or directory > > Not sure how to modify the ebuild for this, ... but I needed to install: > dev-libs/nss-3.12.3-r1 and dev-libs/nspr-4.8, followed by making the following > links: > --to dev-libs/nss libs------------------------------------------------------ > ln -s /usr/lib/nss/libnss3.so /usr/lib/nss/libnss3.so.1d > ln -s /usr/lib/nss/libnssutil3.so.12 /usr/lib/libnssutil3.so.1d > ln -s /usr/lib/nss/libsmime3.so.12 /usr/lib/libsmime3.so.1d > ln -s /usr/lib/nss/libssl3.so.12 /usr/lib/libssl3.so.1d > ln -s /usr/lib/nss/libnss3.so.1d /usr/lib/libnss3.so.1d > --to dev-libs/nspr libs------------------------------------------------------ > ln -s /usr/lib/nspr/libplds4.so /usr/lib/libplds4.so.0d > ln -s /usr/lib/nspr/libplc4.so /usr/lib/libplc4.so.0d > ln -s /usr/lib/nspr/libnspr4.so /usr/lib/libnspr4.so.0d > > after this it runs > I worked this way: add in /etc/fstab: # nano /etc/fstab # Glibc 2.2 and above expects tmpfs to be mounted at / dev / shm for # POSIX shared memory (shm_open, shm_unlink). shm / dev / shm tmpfs nodev, nosuid, noexec 0 0 save changes mount: # mount /dev/shm run google-chrome-bin like this: /usr/bin/google-chrome worked so smoothly, the ebuild if you create dynamic links in a good way (In reply to comment #77) > Just added this ebuild to my local overlay and emerged. No problems while > emerging but running is getting me this error: > > eli@llama ~ $ google-chrome > /opt/google/chrome/google-chrome: > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' > not found (required by /opt/google/chrome/google-chrome) > > I am guess that the latest version of gcc does not support the C++ v3.4.9 ABI. > Is there something I can do? > This binary requires the C++ runtime from >=sys-devel/gcc-4.2 If you get the \"version \`GLIBCXX_3.4.9' not found\" error message, switch your active gcc to a version >=4.2 with gcc-config (In reply to comment #80) > (In reply to comment #77) > > Just added this ebuild to my local overlay and emerged. No problems while > > emerging but running is getting me this error: > > > > eli@llama ~ $ google-chrome > > /opt/google/chrome/google-chrome: > > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' > > not found (required by /opt/google/chrome/google-chrome) > > > > I am guess that the latest version of gcc does not support the C++ v3.4.9 ABI. > > Is there something I can do? > > > > This binary requires the C++ runtime from >=sys-devel/gcc-4.2 > > If you get the \"version \`GLIBCXX_3.4.9' not found\" error message, switch > your active gcc to a version >=4.2 with gcc-config > That did it. I was using an older version of gcc. Once I used gcc-config everything was all better. Could a check be added to the ebuild to warn the user that a certain version of gcc is required? Created attachment 215424 [details]
EBuild for the Current Beta from Google
Hacked the 4.0.223.11.ebuild to do the ebuild for the Beta release
Created attachment 216155 [details]
www-client/google-chrome-bin-4.0.288.1-r35555.ebuild
Do people actually still use this?
In any case, media-libs/jpeg now provides libjpeg.so.7 while the 4.0.288.1 binary needs libjpeg.so.62. The old soname is now provided by media-libs/jpeg-compat; deps updated to match.
I absolutely still use it - Using the exact same browser as I do on Windows & the Mac is a big plus. Many thanks for your continued efforts! (In reply to comment #84) > (In reply to comment #83) > > Do people actually still use this? > I absolutely still use it - Using the exact same browser as I do on Windows & > the Mac is a big plus. Originally I wrote this ebuild because it had some advantages over www-client/chromium-bin, but now we have www-client/chromium building from source. I don't feel like www-client/google-chrome-bin is very necessary anymore. On the other hand, I guess we do have www-client/mozilla-firefox for building from source and www-client/mozilla-firefox-bin for the official binaries, though partly that's because Firefox takes forever to build. Chromium isn't that bad, though it isn't a short build either. for web development, just another browser/renderer to check pages. funny menu bar behavior on *.wikipedia.org seams to be fixed. Chromium takes about 45 minutes to compile on my C2D 2 Ghz laptop. I beside the obvious differences, what are the difference between Chromium-bin and Chrome? Is Chromium-bin provided by Gentoo Devs or Google? I don't see much reason to provide Google Chrome, except for the fact it is the official product. I think you might be able to do it something like Stable vs Beta vs Dev. Make Chrome only avliable for stable maybe hardmask beta's. Then Chromium is the beta with the dev releases hard masked? in google-chrome-bin-9999.ebuild - Rajat Vig - 2010-01-06 20:08 0000 change that silly "../../../../usr" to a straight up "/usr" didn't work like that on my system for some reason, even though it logically should have... I got this before I changed it: /opt/google/chrome/google-chrome: error while loading shared libraries: libnss3.so.1d: cannot open shared object file: No such file or directory because all the symlinks in /opt/google/chrome were broken. but still, I get this: /opt/google/chrome/google-chrome: /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /opt/google/chrome/google-chrome) (In reply to comment #88) > but still, I get this: > > /opt/google/chrome/google-chrome: > /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6: version `GLIBCXX_3.4.9' > not found (required by /opt/google/chrome/google-chrome) Make sure you gcc-select a 4.2 compiler or newer, see comment #80. Either the check in postinst isn't perfect or you ignored the warning... why is this not in portage? Created attachment 219913 [details]
Current unstable patched for newer nss/nspr
Fixing the symlinks for newer nspr and nss.
(In reply to comment #90) > why is this not in portage? > Because from the ebuild: This Chrome binary package is from the developer preview channel. If we were grabbing the proper release meant for public consumption, it'd be a different story. (In reply to comment #83) > Created an attachment (id=216155) [details] > www-client/google-chrome-bin-4.0.288.1-r35555.ebuild > The current magig number / ebuild name is google-chrome-bin-5.0.322.2-r38810.ebuild dosym on nss/nspr libraries should link to /usr/lib/nss and /usr/lib/nspr subfolders respectively (or /usr/lib64). (In reply to comment #94) > dosym on nss/nspr libraries should link to /usr/lib/nss and /usr/lib/nspr > subfolders respectively (or /usr/lib64). Not since dev-libs/nspr-4.8.3-r2 and dev-libs/nss-3.12.5-r1 , see the ChangeLogs or http://bheekly.blogspot.com/2010/02/gentoo-mozilla-team-meeting-decisions.html . chromium-bin-5.0.308.0_p37385 is now broken with upgrade to media-libs/jpeg-8. Needs libjpeg.so.62 which doesn't exist anymore. Created attachment 221707 [details] www-client/google-chrome-bin-5.0.355.0-r39561.ebuild (In reply to comment #96) > chromium-bin-5.0.308.0_p37385 is now broken with > upgrade to media-libs/jpeg-8. Needs libjpeg.so.62 > which doesn't exist anymore. Sure it does. It was named media-libs/jpeg-compat for a while, but now it's a slot of media-libs/jpeg. (In reply to comment #92) > (In reply to comment #90) > > why is this not in portage? > > > > Because from the ebuild: > This Chrome binary package is from the developer preview channel. > > If we were grabbing the proper release meant for public consumption, it'd be a > different story. > This no longer seems to be true. When on youtube today it had a link on the bottom to download chrome. It's beta, but for public consumption. Seems like that should suffice for a ~arch addition to the tree -- at least from a non-developer / user prospective ;-) These are the d/l options: http://www.google.com/chrome/eula.html?brand=CHFH&utm_source=en-et-yt-ftr-lx&utm_medium=et&utm_campaign=en (In reply to comment #98) > (In reply to comment #92) > > (In reply to comment #90) > > > why is this not in portage? > > > > > > > Because from the ebuild: > > This Chrome binary package is from the developer preview channel. > > > > If we were grabbing the proper release meant for public consumption, it'd be a > > different story. > > > > This no longer seems to be true. When on youtube today it had a link on the > bottom to download chrome. It's beta, but for public consumption. Seems like > that should suffice for a ~arch addition to the tree -- at least from a > non-developer / user prospective ;-) > > These are the d/l options: > http://www.google.com/chrome/eula.html?brand=CHFH&utm_source=en-et-yt-ftr-lx&utm_medium=et&utm_campaign=en > www-client/chromium ~arch=beta p.mask=unstable -key=live is already in Portage, has the same releases as Chrome. (In reply to comment #99) > (In reply to comment #98) > > (In reply to comment #92) > > > (In reply to comment #90) > > > > why is this not in portage? > > > > > > > > > > Because from the ebuild: > > > This Chrome binary package is from the developer preview channel. > > > > > > If we were grabbing the proper release meant for public consumption, it'd be a > > > different story. > > > > > > > This no longer seems to be true. When on youtube today it had a link on the > > bottom to download chrome. It's beta, but for public consumption. Seems like > > that should suffice for a ~arch addition to the tree -- at least from a > > non-developer / user prospective ;-) > > > > These are the d/l options: > > http://www.google.com/chrome/eula.html?brand=CHFH&utm_source=en-et-yt-ftr-lx&utm_medium=et&utm_campaign=en > > > > www-client/chromium ~arch=beta p.mask=unstable -key=live > is already in Portage, has the same releases as Chrome. > Chromium does not have support for H.264. Therefore no youtube videos in HTML5. With google-chrome-bin I can watch html5 videos in youtube. Can't do that with chromium, firefox or any other browser that I have tried so far in Linux. (In reply to comment #100) > Chromium does not have support for H.264. Therefore no youtube videos in HTML5. > With google-chrome-bin I can watch html5 videos in youtube. Can't do that with > chromium, firefox or any other browser that I have tried so far in Linux. Have you tried? The chromium-bin that upstream provides is indeed neutered, but our www-client/chromium is patched to be able to play MPEG-4. (In reply to comment #101) > (In reply to comment #100) > > Chromium does not have support for H.264. Therefore no youtube videos in HTML5. > > With google-chrome-bin I can watch html5 videos in youtube. Can't do that with > > chromium, firefox or any other browser that I have tried so far in Linux. > > Have you tried? The chromium-bin that upstream provides is indeed neutered, > but our www-client/chromium is patched to be able to play MPEG-4. > My apologies, I was talking about chromium-bin. I will compile chromium to try this out. Well, the current -9999 does not run because of the missing libjpeg.so.62. There's already some deaf man's code with links from /opt/google/chrome/lib.. to /usr/lib64/, let's add as link from /opt/google/chrome/libjpeg.so.62 to /usr/lib64/libjpeg.so (does not crash here on amd64), or add media-libs/jpeg:62 to RDEPEND. I'll do the second here http://svn.xmw.de/gentoo-overlay/ . Created attachment 221893 [details] nspr/nss version handling, jpeg 62 and QA issue fix?! (In reply to comment #91) > Fixing the symlinks for newer nspr and nss. @Denis: if you patch for the newest versions, you should mention them in RDEPEND. The links point to nowhere with stable nss/nspr after regular emerge. @all: I think that the unstable versions of nss/nspr were not crucial. Added some code to divert between the version. - for i in lib{nss{,util},smime,ssl}3.so.1d \ - lib{pl{ds,c},nspr}4.so.0d ; do - dosym ../../../../usr/$(get_libdir)/${i%.*} \ + if has_version ">=dev-libs/nss-3.12.5-r1" ; then + MY_NSS_SUB="" + else + MY_NSS_SUB="nss/" + fi + if has_version ">=dev-libs/nspr-4.8.3-r3" ; then + MY_NSPR_SUB="" + else + MY_NSPR_SUB="nspr/" + fi + for i in ${MY_NSS_SUB}lib{nss{,util},smime,ssl}3.so.1d \ + ${MY_NSPR_SUB}lib{pl{ds,c},nspr}4.so.0d ; do + dosym /usr/$(get_libdir)/${i%.*} \ ${CHROME_HOME}/${i##*/} done I although added the media-libs/jpeg:62 dependency and opt/google/chrome/libffmpegsumo.so to QA_PRESTRIPPED and QA_TEXTRELS. Have fun! Compiled chromium (~)5.0.307.11 and I have no complaints with it. Works like a charm. google-chrome-bin crashed on when I tried to upload a picture on my tumblr blog, chromium does not. HTML5 on youtube works perfectly as well. I think I may have finally found a browser that I am going to stick with. http://dl.google.com/linux/deb/pool/main/g/google-chrome-unstable/google-chrome-unstable_5.0.335.0-r39561_amd64.deb from the ebuild name google-chrome-bin-5.0.335.0-r39561.ebuild is outdated again. Does anyone know the new name? (In reply to comment #106) > Does anyone know the new name? As mentioned all the way back in comment #19, $ wget -qO- http://dl.google.com/linux/deb/dists/stable/main/binary-amd64/Packages ... Filename: pool/main/g/google-chrome-unstable/google-chrome-unstable_5.0.366.2-r43280_amd64.deb We're plannning on dropping chromium-bin (sync with releases impossible, based on buildbot output, has problems with tcmalloc, ...). I will soon add this to portage as the new binary alternative, just a few edits left in the ebuild to clean (based on work from this bugreport and current chromium-bin ebuild) Thanks everyone for suggestions and for your patience I've just updated and reviewed the ebuild to the latest versions. Unstable has different revision numbers for x86 and amd64. I would suggest a name change to just google-chrome, since the source is closed and there is no "source" version to collide with this one. Feel free to take a look at http://svn.xmw.de/websvn/gentoo-overlay/www-client/google-chrome-bin/ Unfortunately the font isn't working on my system right now, I've to verify and fix this on a second one. And Google supports more languages as repoman full can take, en-GB en-US es-419 (aka es-americas) fil pt-BR pt-PT zh-CN zh-TW @Bernard: If you want, I can commit this to sunrise overlay and put it into tree, once my bug has been processed. ;-) Sure, feel free to add it to Sunrise :) I have a few changes of my own to the ebuild here: http://cafarelli.fr/websvn/listing.php?repname=voyageur-overlay&path=/www-client/google-chrome-bin/ For portage inclusion, we are waiting for some upstream news on older files mirroring/availabilty, nss/nspr lib names Created attachment 233073 [details]
www-client/google-chrome-bin-6.0.408.1_p47574.ebuild
Yet another ebuild for google-chrome-bin. This one cherry picks some ideas from other ebuilds.
I added a CHAN variable to select the channel, this makes it very easy to revbump for stable/beta/unstable channel. Just mv the correct ebuild for that channel to the new version and you're done.
LINGUAS are handled similar to Michael's ebuild in #109, but with consistant naming for the rest of portage (underscores instead of dashes).
I copied some of the bug handling from Bernard's ebuild in #110.
While I disagree with it, I liked Michael's idea of being able to remove the sandbox. So I add a suid USE to control weather sandbox is installed and suid, or not installed.
If anyone has any improvement ideas, let me know. I apologize in advance for the mixed tabs and spaces, but I don't feel the need to devote time to fixing it. Thanks all for the ideas.
Created attachment 233885 [details] www-client/google-chrome-5.0.375.55-r47796.ebuild (latest stable) Forgive me if i'm blind, but I haven't seen any stable ebuilds of this. If there's another bug for that, then I apologize in advance. I modified #110's ebuild to use the latest stable (5.0.375.55-r47796), renamed it to google-chrome as per #109's comment, fixed some tabs to spaces in the ebuild, and updated the elog portion. ebuild can be renamed to the latest version, and all should be well. (command in the top of the ebuild can fetch latest names) wget -qO- http://dl.google.com/linux/deb/dists/stable/main/binary-amd64/Packages|grep Filename > I modified #110's ebuild to use the latest stable (5.0.375.55-r47796), renamed
> it to google-chrome as per #109's comment, fixed some tabs to spaces in the
> ebuild, and updated the elog portion.
sorry, I meant this is a modified version of #111's ebuild not #110
(In reply to comment #112) > ... fixed some tabs to spaces in the ebuild ... http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect4 ==Rules for writing an ebuild file== Since ebuild files are really just shell scripts, you should use your editor's shell-script mode for editing them. You should use proper indentation, using only tab characters -- no spaces. Make sure you set up your editor to put tab stops at 4 spaces. Always make sure you use braces around your environment variables; e.g. ${P} instead of just $P. Created attachment 233893 [details] google-chrome-5.0.375.55-r47796.ebuild (Latest stable) (In reply to comment #114) > (In reply to comment #112) > > ... fixed some tabs to spaces in the ebuild ... > > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap2_sect4 > > ==Rules for writing an ebuild file== > > Since ebuild files are really just shell scripts, you should use your editor's > shell-script mode for editing them. You should use proper indentation, using > only tab characters -- no spaces. Make sure you set up your editor to put tab > stops at 4 spaces. Always make sure you use braces around your environment > variables; e.g. ${P} instead of just $P. > Thanks, I wasn't aware. most of the ebuild was spaces so I thought that was correct. Fixed in new version I'm uploading now. Hi, i've updated my ebuilds with the comments and bugfixes from Bernard, thanks for this part. Unfortunately the fonts don't work. Can someone with a visible font rendering please past `eix -I -c | pastebin`? Mine is http://pastebin.com/3JbTNrV1 . I also get following, but i don't think it's critical. michael@io ~ % google-chrome ./chrome: /lib/libz.so.1: no version information available (required by ./chrome) /opt/google/chrome/chrome: /lib/libz.so.1: no version information available (required by /opt/google/chrome/chrome) /proc/self/exe: /lib/libz.so.1: no version information available (required by /proc/self/exe) (In reply to comment #116) > Hi, > > i've updated my ebuilds with the comments and bugfixes from Bernard, thanks for > this part. Unfortunately the fonts don't work. Can someone with a visible font > rendering please past `eix -I -c | pastebin`? Mine is > http://pastebin.com/3JbTNrV1 > . > > I also get following, but i don't think it's critical. > michael@io ~ % google-chrome > ./chrome: /lib/libz.so.1: no version information available (required by > ./chrome) > /opt/google/chrome/chrome: /lib/libz.so.1: no version information available > (required by /opt/google/chrome/chrome) > /proc/self/exe: /lib/libz.so.1: no version information available (required by > /proc/self/exe) > I had that problem too when I was experimenting with the RPM and .deb's in my chroot. seemed like an isolated issue. in any case, here's my paste http://pastebin.com/sMe7ZfUw > > I also get following, but i don't think it's critical.
> > michael@io ~ % google-chrome
> > ./chrome: /lib/libz.so.1: no version information available (required by
> > ./chrome)
> > /opt/google/chrome/chrome: /lib/libz.so.1: no version information available
> > (required by /opt/google/chrome/chrome)
> > /proc/self/exe: /lib/libz.so.1: no version information available (required by
> > /proc/self/exe)
Also, If it's worth anything; I get these same errors too. they don't seem to effect the functionality at all.
Also, those
(In reply to comment #115) > Created an attachment (id=233893) [details] > google-chrome-5.0.375.55-r47796.ebuild (Latest stable) I switched to using _p instead of -r for the svn revision number, because you can still do ebuild revision bumps. For example if you need to fix something in the ebuild and you have -r44796, the only way to bump the ebuild is hardcode the svn revision and do -r44797. When using _p44796 you can still do _p47796-r1. > Thanks, I wasn't aware. most of the ebuild was spaces so I thought that was > correct. Fixed in new version I'm uploading now. > Thanks for fixing that. Created attachment 233907 [details] google-chrome-5.0.375.55_p47796-r1.ebuild (Latest stable release, renamed to _p instead of -r as per #119) (In reply to comment #119) > (In reply to comment #115) > > Created an attachment (id=233893) [details] [details] > > google-chrome-5.0.375.55-r47796.ebuild (Latest stable) > > I switched to using _p instead of -r for the svn revision number, because you > can still do ebuild revision bumps. For example if you need to fix something in > the ebuild and you have -r44796, the only way to bump the ebuild is hardcode > the svn revision and do -r44797. When using _p44796 you can still do > _p47796-r1. > > > Thanks, I wasn't aware. most of the ebuild was spaces so I thought that was > > correct. Fixed in new version I'm uploading now. > > > > Thanks for fixing that. > That makes so much sense, I didn't realize what that was for until you pointed it out. fixed my latest stable ebuild, added -r1 to be sure it worked. I'm typing this post from chrome 5.0.375.55_p47796-r1 right now. Created attachment 233911 [details]
www-client/google-chrome-5.0.375.55_p47796-r2.ebuild (latest stable) fixed icon install, added block for -bin, cleaned up syntax
updated the latest stable ebuild.
-added a block for -bin
-fixed the newicon installation (only worked on a reinstall, not on a fresh install. it now works)
-has ~x86 ~amd64 keywords, forgot to mention that earlier. (it's the latest stable, so i think ~ARCH is ok right?)
-cleaned up some more tab business
Created attachment 233923 [details]
Added the new build with a dependency to media-libs/libpng:1.2
Added the new build with a dependency to media-libs/libpng:1.2
(In reply to comment #122) > Created an attachment (id=233923) [details] > Added the new build with a dependency to media-libs/libpng:1.2 > > Added the new build with a dependency to media-libs/libpng:1.2 > Thanks, does this not work with libpng 1.4? only 1.2? has anyone tested? Why libpng:1.2 as a dependency instead of libpng:0? This will be a major pain in the butt for a stable tree user. In fact the correct dependency on 1.2, the DEPEND should be =media-libs/libpng-1.2* which matches slotted 1.2 for ~arch, and 1.2.43-r2 for stable Created attachment 234013 [details]
www-client/google-chrome-5.0.375.55_p47796-r4.ebuild (latest stable) fix libpng:1.2 to =libpng-1.2*
fixed to =media-libs/libpng-1.2* as per #125's comment.
by the way, the newicon line I fixed in -r2 should apply to the dev/unstable ebuilds above. if anyone is still using them, it should be:
newicon "${D}${CHROME_HOME}/product_logo_256.png" "${MY_PN}.png"
not
newicon "${CHROME_HOME}/product_logo_256.png" "${MY_PN}.png"
otherwise emerge complains about not being able to find it on a new install. but works on a reinstall.
After putting chrome through some tests, it seem more stable than chromium. in fact chromium doesn't even pass the javascript test @ http://service.futuremark.com/peacekeeper/index.action HTML5 @ youtube seems working too. After using chrome for 2yrs on windows, this is probably the closest it's come to working flawlessly on Linux. I don't see why this shouldn't be in the main tree yet. (besides needing testing on other ARCH's i suppose) I picked up google-chrome-5.0.375.55_p47796-r4.ebuild and put it my overlay, and installed it (32-bitinstall). And the text in the menus is missing. See the attachment. I tried a new user, and the same thing. Created attachment 234047 [details]
Missing text.
(In reply to comment #128) > I picked up google-chrome-5.0.375.55_p47796-r4.ebuild and put it my overlay, > and installed it (32-bitinstall). And the text in the menus is missing. See the > attachment. I tried a new user, and the same thing. > Hmm... I just tried this ebuild on a sabayon i686 livecd, and fonts worked. however i did find a bug in some of the library linking libnspr4.so.0d -> /usr/lib/nss/libnspr4.so libplc4.so.0d -> /usr/lib/nss/libplc4.so libplds4.so.0d -> /usr/lib/nss/libplc4.so should be: libnspr4.so.0d -> /usr/lib/nspr/libnspr4.so libplc4.so.0d -> /usr/lib/nspr/libplc4.so libplds4.so.0d -> /usr/lib/nspr/libplc4.so I don't know why it's linking to a directory that doesn't exist (nss) I'll investigate some more. also, about the font thing, I think maybe we're missing a dependency? I know by default google chrome uses Times New Roman, Arial, and Monospace or Liberation Mono. Created attachment 234051 [details]
fixed symlink issues for 32bit, cleaned up, better readable
I think I fixed the symlink issues. (moved some lines from chromium-bin ebuild) it emerges fine on 32bit and 64bit now. but I still don't see any icon issues. I do see some deps that chromium-bin uses that we don't have.
can someone on 32bit with the text issue try adding this to the bottom of the RDEPEND=
|| (
x11-themes/gnome-icon-theme
x11-themes/tango-icon-theme
x11-themes/xfce4-icon-theme
)"
(In reply to comment #131) > Created an attachment (id=234051) [details] > fixed symlink issues for 32bit, cleaned up, better readable > > I think I fixed the symlink issues. (moved some lines from chromium-bin ebuild) > it emerges fine on 32bit and 64bit now. but I still don't see any icon issues. > I do see some deps that chromium-bin uses that we don't have. > > can someone on 32bit with the text issue try adding this to the bottom of the > RDEPEND= > > || ( > x11-themes/gnome-icon-theme > x11-themes/tango-icon-theme > x11-themes/xfce4-icon-theme > )" > also try virtual/ttf-fonts we don't have that in there either. I have both gnome-icon-theme and virtual/ttf-fonts installed. I don't think its a font issue. If it was, it won't show my.yahoo.com or google.com. Does it have to do with the fact that I am running xorg-server 1.8.1 and all Xorg libs are from that version. And google-chrome is somehow expecting something old. But strangely enough, chromium-bin is able to run fine and doesn't suffer from this issue. (In reply to comment #133) > I have both gnome-icon-theme and virtual/ttf-fonts installed. I don't think its > a font issue. If it was, it won't show my.yahoo.com or google.com. > > Does it have to do with the fact that I am running xorg-server 1.8.1 and all > Xorg libs are from that version. And google-chrome is somehow expecting > something old. > > But strangely enough, chromium-bin is able to run fine and doesn't suffer from > this issue. > this baffles me, I've added every dep that chromium-bin has to my local ebuild, and ran in my 32bit chroot that has font issues and I haven't been able to get menu fonts to work either. I doubt it's a Xorg issues, my chroot has stable xorg. but i do think it's something we're missing since it works fine in a sabayon i686 environment. but not a minimal/bare environment. (In reply to comment #134) > (In reply to comment #133) > > I have both gnome-icon-theme and virtual/ttf-fonts installed. I don't think its > > a font issue. If it was, it won't show my.yahoo.com or google.com. > > > > Does it have to do with the fact that I am running xorg-server 1.8.1 and all > > Xorg libs are from that version. And google-chrome is somehow expecting > > something old. > > > > But strangely enough, chromium-bin is able to run fine and doesn't suffer from > > this issue. > > > > this baffles me, I've added every dep that chromium-bin has to my local ebuild, > and ran in my 32bit chroot that has font issues and I haven't been able to get > menu fonts to work either. > > I doubt it's a Xorg issues, my chroot has stable xorg. but i do think it's > something we're missing since it works fine in a sabayon i686 environment. but > not a minimal/bare environment. > I think we can safely rule out fonts too. I just installed 50+ fonts into my 32bit chroot, and still the same issue. I've had no luck getting the fonts working in my 32bit chroot install. everything from menus to options pages, to task manager have missing fonts. all other font in webpages works fine though. and no valuable error information either. if anyone has a solution, that would be great so we can get closer to a tree inclusion. (In reply to comment #136) > I've had no luck getting the fonts working in my 32bit chroot install. > everything from menus to options pages, to task manager have missing fonts. all > other font in webpages works fine though. and no valuable error information > either. if anyone has a solution, that would be great so we can get closer to a > tree inclusion. > also worthy of noting, that this happens when installing the 32bit .rpm without the ebuild(not sure about the .deb) so possibly this is some sort of upstream bug or that our gentoo 32bit libs are incompatible somehow? 64bit works almost flawlessly though. (better than chromium in my experience) (In reply to comment #137) > (In reply to comment #136) > > I've had no luck getting the fonts working in my 32bit chroot install. > > everything from menus to options pages, to task manager have missing fonts. all > > other font in webpages works fine though. and no valuable error information > > either. if anyone has a solution, that would be great so we can get closer to a > > tree inclusion. > > > > also worthy of noting, that this happens when installing the 32bit .rpm without > the ebuild(not sure about the .deb) so possibly this is some sort of upstream > bug or that our gentoo 32bit libs are incompatible somehow? > > 64bit works almost flawlessly though. (better than chromium in my experience) > Actually, sorry I may have spoke too soon. google-chrome-stable_current_i386.rpm works fine in the 32bit chroot. so it's definitely something we're doing wrong. I'll dig deeper, but I'm no coder or anything. manually unpacking google-chrome-stable_5.0.375.55-r47796_i386.deb and extracting to appropriate locations, and symlinking libs works fine. but I don't see any difference between this and how the ebuild does it. I double checked and they are going to the same locations. the unpack and prepare stages seem fine. I can run google-chrome from the work directory both as root and a normal user and fonts work fine. so something in the src_install() is wrong for 32bit users. AHA, I found the issue. no language is being turned on by default. if you do something like; LINGUAS="en_US" emerge google-chrome it works fine. so how do we handle the langs? Isn't it supposed to fetch the system language somehow? (In reply to comment #140) > AHA, I found the issue. no language is being turned on by default. if you do > something like; > > LINGUAS="en_US" emerge google-chrome > > it works fine. so how do we handle the langs? Isn't it supposed to fetch the > system language somehow? > LINGUAS should be initialized by the ebuild itself, right? I mean a package supports particular languages and ebuild should specify that. (In reply to comment #140) > AHA, I found the issue. no language is being turned on by default. if you do > something like; I was actually just about to hit Commit asking if that could be the problem, then saw I had a new email from bugzilla :P > LINGUAS="en_US" emerge google-chrome > > it works fine. so how do we handle the langs? Isn't it supposed to fetch the > system language somehow? Well, the 'system' language is set by LINGUAS in make.conf. However, things shouldn't break if it is unset. Let me look into how other ebuilds handle this. (In reply to comment #142) > (In reply to comment #140) > > AHA, I found the issue. no language is being turned on by default. if you do > > something like; > > I was actually just about to hit Commit asking if that could be the problem, > then saw I had a new email from bugzilla :P > > > LINGUAS="en_US" emerge google-chrome > > > > it works fine. so how do we handle the langs? Isn't it supposed to fetch the > > system language somehow? > > Well, the 'system' language is set by LINGUAS in make.conf. However, things > shouldn't break if it is unset. Let me look into how other ebuilds handle this. > ideally LINGUAS= should be specified in make.conf but not everybody does that. maybe we can somehow fetch the language from /etc/locale.gen or, if none are specified, just enable all of them? (or in our case, don't rm all of them in the src_install() phase) Created attachment 234059 [details]
www-client/google-chrome-5.0.375.55_p47796-r6.ebuild
This includes all of chickaroo's fixes plus fixes local installation if LINGUAS is unset.
I also properly fixed the symlinking (was just a typo nss instead of nspr, oops).
chickaroo, what was the "dodir ${CHROME_HOME}/nss-nspr" for? I'm sure you didn't want to create a directory named 'nss-nspr' without anything in it. I removed this.
(In reply to comment #144) > Created an attachment (id=234059) [details] > www-client/google-chrome-5.0.375.55_p47796-r6.ebuild > > This includes all of chickaroo's fixes plus fixes local installation if LINGUAS > is unset. > > I also properly fixed the symlinking (was just a typo nss instead of nspr, > oops). > > chickaroo, what was the "dodir ${CHROME_HOME}/nss-nspr" for? I'm sure you > didn't want to create a directory named 'nss-nspr' without anything in it. I > removed this. > nice! thanks for fixing :) that's a much prettier way of doing the symlinking. the nss-nspr was from the chromium-bin ebuild i copied the symlinking from. I honestly had no idea if it was needed or not. :) (In reply to comment #123) > Thanks, does this not work with libpng 1.4? only 1.2? > > has anyone tested? > The "chrome" binary seems to be linked against both. I have other packages that depend on 1.2 or I would try removing it. The deps from the official repo say "libpng12-0". Tested google-chrome-bin-5.0.375.55_p47796-r6.ebuild on amd64, x86 and ~x86 with and without languages. seems to be working great now :) Thanks again Nathan. Also, I noticed you added the -bin again. is this necessary since there isn't any source version? (In reply to comment #148) > Also, I noticed you added the -bin again. is this necessary since there isn't > any source version? > Completely by accident, this is how I have it in my local repo, and didn't change the name before uploading. If you look in the Description column I have it without the -bin, and this is what I intended ;) Created attachment 234065 [details] same as -r6 but slight dep cleanup and removed some blank spaces/tabs (In reply to comment #149) > (In reply to comment #148) > > Also, I noticed you added the -bin again. is this necessary since there isn't > > any source version? > > > > Completely by accident, this is how I have it in my local repo, and didn't > change the name before uploading. If you look in the Description column I have > it without the -bin, and this is what I intended ;) Oh, after i just spent 15mins changing it back to -bin so it would emerge properly again with that name :P in any case, i changed it back. and also added some of my local changes (removed some blank spaces/tabs and cleaned up deps a bit, mostly pulled from chromium-bin and chromium ebuilds) Created attachment 234067 [details]
www-client/google-chrome-6.0.422.0_p48573.ebuild (latest UNSTABLE build from google) same ebuild as the stable, except keywords removed and ewarn added again.
updated the latest unstable here too if anyone wants it. (i'm typing this post from 6.x so it seems to work, but I'll be sticking with stable)
Hi, i've systems here with LINUGAS="de en en_US en_GB" and i can enable/disable font rendering, or text display by export LANG="de_DE.UTF-8" / unset LANG. Plus it only works from console since the default LANG isn't setup correctly within the `.desktop` file execution. I've traced down the visibility of a front to the value of `--lang=` beeing empty. This output is from a google-chrom invocation w/o LANG env var but en_US.pak installed. 26033 pts/8 Sl+ 0:00 ./chrome 26034 pts/8 S+ 0:00 ./chrome 26035 pts/8 S+ 0:00 /opt/google/chrome/chrome --type=zygote 26053 pts/8 Sl+ 0:00 /opt/google/chrome/chrome --type=renderer --lang=en-US --force-fieldtest=DnsImpact/_default_enabled_prefetch/GlobalSdch/_global_enable_sdch/ --channel =26033.0x4394600.672620447 I think it isn't wise to rely on the values of LINGUAS from make.conf or the content of /etc/locale.gen. I think we need at least the en_US.pak as a default fallback langugae and - preferrably in my current opinion - the whole set of languages. I think that tese spared 10MB aren't worth the trouble we've had here or of any future main tree bugs. my 2 cents since we all agree in just naming it www-client/google-chrome ... Created attachment 234607 [details]
www-client/google-chrome-5.0.375.70_p48679 (version bump to latest stable)
version bump. latest official stable released today.
(In reply to comment #152) > Hi, i've systems here with LINUGAS="de en en_US en_GB" and i can enable/disable > font rendering, or text display by export LANG="de_DE.UTF-8" / unset LANG. > Plus it only works from console since the default LANG isn't setup correctly > within the `.desktop` file execution. I've traced down the visibility of a > front to the value of `--lang=` beeing empty. This output is from a > google-chrom invocation w/o LANG env var but en_US.pak installed. > > 26033 pts/8 Sl+ 0:00 ./chrome > 26034 pts/8 S+ 0:00 ./chrome > 26035 pts/8 S+ 0:00 /opt/google/chrome/chrome --type=zygote > 26053 pts/8 Sl+ 0:00 /opt/google/chrome/chrome --type=renderer > --lang=en-US > --force-fieldtest=DnsImpact/_default_enabled_prefetch/GlobalSdch/_global_enable_sdch/ > --channel > =26033.0x4394600.672620447 > > I think it isn't wise to rely on the values of LINGUAS from make.conf or the > content of /etc/locale.gen. I think we need at least the en_US.pak as a default > fallback langugae and - preferrably in my current opinion - the whole set of > languages. I think that tese spared 10MB aren't worth the trouble we've had > here or of any future main tree bugs. my 2 cents > we enable all by default now if no lang is set. (you're right the 10MB isn't worth it at all) but I don't know what you mean about the .desktop file. Mine has a ton of langs in it for the description, but I don't see any lang= in it. have you tested any of our recent ebuilds? does it work correctly? and do you have any suggestions to fix this if it doesn't? thanks Created attachment 234795 [details]
www-client/google-chrome-6.0.427.0_p49010 (version bump, latest unstable)
version bump to latest official unstable (6.0.427.0-r49010)
Created attachment 235913 [details]
www-client/google-chrome-bin-6.0.437.3_p50164.ebuild
Remove "-bin" from .deb download location.
(In reply to comment #157) > Created an attachment (id=235913) [details] > www-client/google-chrome-bin-6.0.437.3_p50164.ebuild > > Remove "-bin" from .deb download location. > Eh, I might have missed something here. But the above is needed, at least for me, to actually be able to download the .deb. Even though /we/ want the "-bin" as a suffix to the filename, Google does not. So it needs to be removed when using ${PN}. Also versionbumped to latest unstable. (In reply to comment #158) > (In reply to comment #157) > > Created an attachment (id=235913) [details] [details] > > www-client/google-chrome-bin-6.0.437.3_p50164.ebuild > > > > Remove "-bin" from .deb download location. > > > > Eh, I might have missed something here. But the above is needed, at least for > me, to actually be able to download the .deb. Even though /we/ want the "-bin" > as a suffix to the filename, Google does not. So it needs to be removed when > using ${PN}. > > Also versionbumped to latest unstable. > and it's not needed when the ebuild is named google-chrome and not google-chrome-bin :) thanks, I probably won't be able to bump anymore. but I think we should keep the name consistent. is there really a need for -bin when they only offer a binary? chromium is the source version. and google-chrome is the bin. so it seems unnecessary. and the -bin at the end just looks ugly IMO *** Bug 324865 has been marked as a duplicate of this bug. *** (In reply to comment #160) > *** Bug 324865 has been marked as a duplicate of this bug. *** > I could not download file... neit google-chrome-bin # ebuild google-chrome-bin-6.0.437.3_p50164.ebuild digest >>> Downloading 'http://dl.google.com/linux/deb/pool/main/g/google-chrome-bin-unstable/google-chrome-unstable_6.0.437.3-r50164_i386.deb' --2010-07-08 03:11:17-- http://dl.google.com/linux/deb/pool/main/g/google-chrome-bin-unstable/google-chrome-unstable_6.0.437.3-r50164_i386.deb Resolvendo dl.google.com... 64.233.163.91, 64.233.163.93, 64.233.163.136, ... Conectando-se a dl.google.com|64.233.163.91|:80... conectado. A requisição HTTP foi enviada, aguardando resposta... 404 Not Found 2010-07-08 03:11:18 ERRO 404: Not Found. >>> Downloading 'http://www.las.ic.unicamp.br/pub/gentoo/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb' --2010-07-08 03:11:18-- http://www.las.ic.unicamp.br/pub/gentoo/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb Resolvendo www.las.ic.unicamp.br... 143.106.60.118 Conectando-se a www.las.ic.unicamp.br|143.106.60.118|:80... conectado. A requisição HTTP foi enviada, aguardando resposta... 404 Not Found 2010-07-08 03:11:19 ERRO 404: Not Found. >>> Downloading 'ftp://ftp.las.ic.unicamp.br/pub/gentoo/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb' --2010-07-08 03:11:19-- ftp://ftp.las.ic.unicamp.br/pub/gentoo/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb => “/usr/portage/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb” Resolvendo ftp.las.ic.unicamp.br... 143.106.60.118 Conectando-se a ftp.las.ic.unicamp.br|143.106.60.118|:21... conectado. Acessando como anonymous ... Acesso autorizado! ==> SYST ... feito. ==> PWD ... feito. ==> TYPE I ... feito. ==> CWD (1) /pub/gentoo/distfiles ... feito. ==> SIZE google-chrome-unstable_6.0.437.3-r50164_i386.deb ... feito. ==> PASV ... feito. ==> RETR google-chrome-unstable_6.0.437.3-r50164_i386.deb ... O arquivo “google-chrome-unstable_6.0.437.3-r50164_i386.deb” não foi encontrado. >>> Downloading 'http://gentoo.c3sl.ufpr.br/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb' --2010-07-08 03:11:19-- http://gentoo.c3sl.ufpr.br/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb Resolvendo gentoo.c3sl.ufpr.br... 200.17.202.1 Conectando-se a gentoo.c3sl.ufpr.br|200.17.202.1|:80... conectado. A requisição HTTP foi enviada, aguardando resposta... 404 Not Found 2010-07-08 03:11:20 ERRO 404: Not Found. >>> Downloading 'ftp://gentoo.c3sl.ufpr.br/gentoo/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb' --2010-07-08 03:11:20-- ftp://gentoo.c3sl.ufpr.br/gentoo/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb => “/usr/portage/distfiles/google-chrome-unstable_6.0.437.3-r50164_i386.deb” Resolvendo gentoo.c3sl.ufpr.br... 200.17.202.1 Conectando-se a gentoo.c3sl.ufpr.br|200.17.202.1|:21... conectado. Acessando como anonymous ... Acesso autorizado! ==> SYST ... feito. ==> PWD ... feito. ==> TYPE I ... feito. ==> CWD (1) /gentoo/distfiles ... feito. ==> SIZE google-chrome-unstable_6.0.437.3-r50164_i386.deb ... feito. ==> PASV ... feito. ==> RETR google-chrome-unstable_6.0.437.3-r50164_i386.deb ... O arquivo “google-chrome-unstable_6.0.437.3-r50164_i386.deb” não foi encontrado. !!! Couldn't download 'google-chrome-unstable_6.0.437.3-r50164_i386.deb'. Aborting. !!! Fetch failed for google-chrome-unstable_6.0.437.3-r50164_i386.deb, can't update Manifest my file: http://paste.pocoo.org/show/234883/ (In reply to comment #161) > (In reply to comment #160) > > *** Bug 324865 has been marked as a duplicate of this bug. *** > > > > I could not download file... Read comment #19. $ wget -qO- http://dl.google.com/linux/deb/dists/stable/main/binary-{i386,amd64}/Packages | grep ^Filename: Filename: pool/main/g/google-chrome-beta/google-chrome-beta_5.0.375.99-r51029_i386.deb Filename: pool/main/g/google-chrome-stable/google-chrome-stable_5.0.375.99-r51029_i386.deb Filename: pool/main/g/google-chrome-unstable/google-chrome-unstable_6.0.453.1-r51400_i386.deb Filename: pool/main/g/google-chrome-beta/google-chrome-beta_5.0.375.99-r51029_amd64.deb Filename: pool/main/g/google-chrome-stable/google-chrome-stable_5.0.375.99-r51029_amd64.deb Filename: pool/main/g/google-chrome-unstable/google-chrome-unstable_6.0.453.1-r51400_amd64.deb Bump your ebuild's version to match. They don't keep around downloads of older versions. got rid of this crashy app. Created attachment 240383 [details]
www-client/google-chrome-bin-6.0.472.0-r53024.ebuild
The 6.0 ebuild needs to be bumped to: 6.0.472.14-r54133 -- older files not available anymore. Created attachment 241945 [details]
google-chrome-bin-6.0.472.25-r55113.ebuild
Version bump (unstable).
Icon named as "google-chrome", not "google-chrome-bin", so that the .desktop file will find it.
Created attachment 246806 [details]
Version bump to 7.0.517.0
(In reply to comment #166) > Created an attachment (id=241945) [details] > google-chrome-bin-6.0.472.25-r55113.ebuild > > Version bump (unstable). > Icon named as "google-chrome", not "google-chrome-bin", so that the .desktop > file will find it. > I don't know how the entire ebuild got changed back to google-chrome-bin after it was changed to google-chrome (hence the title of this bug). it doesn't make sense to call it -bin since there is no source version. only binary. chromium is the source. that's my $0.02. I would like to propose that the stable version (which presumably doesn't update too frequently) be added to the main portage tree. This is now in my belak overlay. If it falls behind on updates, let me know and post a bug on bitbucket. I know this is only my opinion but I think this bug should be closed because of the update frequency and how the updates work. In short, it's a pain to update because the files constantly change without much warning unless you also have debian installed (or ubuntu) and see when they change. Also, some people would say just grab the latest. This would be nice, but it won't work because the filename is constantly changing. Also, the checksum keeps changing so on each update you'd need to manifest the ebuild. Again, though, I have it in my overlay and I will attempt to update it as long as people post bugs on it. http://www.bitbucket.org/belak/belak.gentoo/ Agreed. Given the way ebuilds work, upstream is just too volatile. I've installed google-chrome from the overlay and it works smoothly on my old t42 thinkpad laptop. Just a random thought: is www-client/google-chrome any different from www-plugins/google-talkplugin which is already in the portage? Yes, google-talkplugin is merely the Gmail plugin for Google Talk (voice and video chat). Obviously I was asking from the packaging point of you. Kaleb, Pawel: could you point me out why it is ok for googe-talk to sit in the portage and google-chrome can be in the overlay only? This is a feedback for http://phajdan-jr.blogspot.com/2011/05/www-clientchromium-frequent-updates.html because comments are disabled there. Simply put, google-talk is much less frequently updated. Also, there is no open source package for anything like google-talk. Because google-chrome is based off chromium, it provides an alternative already in the tree. Also, google-chrome (similar to chromium-bin) would be a strain on resources, taking talent away from creating new packages and updating other packages. Really, the main reason is because upstream is too active, and unlike other ebuilds, when upstream updates, the ebuild needs an update, or you won't be able to install. (In reply to comment #174) > Kaleb, Pawel: could you point me out why it is ok for googe-talk to sit in the > portage and google-chrome can be in the overlay only? Any developer is free to add google-chrome to the portage tree - I guess that's why this bug is open. Someone decided to add google-talk (that wasn't me), someone maintains picasa I think and so on - as long as they want to maintain those packages, that's fine. For me www-client/chromium is more maintainable than google-chrome, so that's what I maintain. I should have an ebuild in the tree this weekend. In the tree. |
