www-client/chromium-4.0.249.43 builds correctly but does not display web pages. Firefox proves the internet connection is available by being able to navigate and display web pages. Chromium was built using ffpeg.
Please provide enough information to understand what's going on. Are you behind a proxy? What does it mean exactly that it doesn't display web pages? Does it succeed fetching them from the network? Does it display any status or error messages? Does chromium-bin work on your machine? Also, could you post your emerge --info?
I am with three mobile and do not know if I am behind a proxy. I know I do not have my own IP per se. What I mean about not displaying web pages is that you can see that it attempts to retrieve the web pages through the activity in the bottom address status bar. It cannot even render saved web pages. Therefore, I do not think that this is a network issue, but a rendering issue. It is as though a dependency was not picked up.
Please report the bug upstream, <http://code.google.com/p/chromium/issues/entrytemplate=Defect%20on%20Linux>
Your URL does not work.
Sorry, should be <http://code.google.com/p/chromium/issues/entry?template=Defect%20on%20Linux> (or it got badly transformed on form submission). If it still doesn't work, please go to http://new.crbug.com and choose the Linux template.
Chromium bug now filed upstream as bug: http://code.google.com/p/chromium/issues/detail?id=31740
I'm going to reopen the bug and add sanity checks for /dev/shm to the ebuild. Looks like too many users fall into this trap.
Fixed by adding more checks to the ebuild. Thanks for reporting.
The fix is bad and probably does more harm than good. pkg_setup is not really a good place for checking /dev stuff and dying that way. Think about chroots used for building pkgs. It's breaking the ability to this pkg.
Should at minimum check for ${ROOT}, like [[ ${ROOT} = / ]] && whatever Plus mainly, I don't really see how's this a wide issue here, considering this being in default Gentoo /etc/fstab for, like, ages? # glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for # POSIX shared memory (shm_open, shm_unlink). # (tmpfs is a dynamically expandable/shrinkable ramdisk, and will # use almost no memory if not populated with files) shm /dev/shm tmpfs nodev,nosuid,noexec 0 0 Checks like this simply do not belong to ebuilds like this, because it's case of serious user misconfiguration (aka PEBKAC).
Created attachment 221313 [details, diff] chromium-5.0.307.9.ebuild.diff - move the check to pkg_preinst() - make the check non-fatal - don't break chroot/prefix users etc.
Created attachment 221315 [details, diff] chromium-5.0.307.9.ebuild.diff Sorry, left stray stuff in previous one
The check for $ROOT is fine for me, but I'm going to leave it in pkg_setup and leave the die to. Otherwise we're going to get a flood of bogus bug reports, either here or upstream. Thanks for the suggestions and patches.
(In reply to comment #13) > The check for $ROOT is fine for me, but I'm going to leave it in pkg_setup and > leave the die to. Otherwise we're going to get a flood of bogus bug reports, > either here or upstream. Thanks for the suggestions and patches. Why are you making this fatal? It's wrong, it doesn't fail during compile in any way so there's no need to have this as a fatal check. (Also, cf. all the changes to stuff using linux-{mod,info}.eclass recently that makes all these kind of checks non-fatal. All the users that don't have this uncommented *already* *have* a *broken* *setup* affecting multiple other packages in anything from glibc-2.2 above. Wrt the phase, I could care less but man ebuild(5) says this: <snip> pkg_preinst pkg_postinst ... Also commentary for the user should be listed here as it will be displayed last. </snip>
I consider this FIXED (added check for $ROOT). lxnay, I'm open for your patches if this doesn't satisfy you. Some points I'd really want to keep: - check in pkg_setup, so the user doesn't waste his compile time - fatal check, so the user really notices it I'm sorry, but the argument about the users having broken /dev/shm setup and an entry in /etc/fstab doesn't reflect reality. I thought similarly in the beginning, but after a few bogus bug reports that wasted my time, and time of other Chromium developers, I added the check. It's also kind of hurting the reputation of Gentoo, as upstream developers tend to think that all Gentoo systems are broken (like the rxvt case). Again, if you have a patch that would make building it in a chroot or whatever easier, I'm open to use it provided it doesn't violate any of the important points above.
(In reply to comment #15) > Some points I'd really want to keep: > - check in pkg_setup, so the user doesn't waste his compile time > - fatal check, so the user really notices it How are they wasting their compile time? The package is perfectly functional once they've unbroke their /etc/fstab, it doesn't harm compile nor the end result of it in any way. > I'm sorry, but the argument about the users having broken /dev/shm setup and an > entry in /etc/fstab doesn't reflect reality. Hmmm, try something like - well, anything that uses pulseaudio without /dev/shm mounted. Yeah, it doesn't work. You want to add the same check to all ebuilds that have pulseaudio in IUSE or happen to use pulseaudio in some way? > Again, if you have a patch that would make building it in a chroot or whatever > easier, I'm open to use it provided it doesn't violate any of the important > points above. The only patch that makes sense here it to make chromium spit out "uncomment the darned /dev/shm line in fstab which has been needed since glibc-2.2 and you shouldn't have messed with it in the first place" at runtime. Why doesn't upstream provide any such message and instead leaves people with a browser that doesn't render any webpage?
(In reply to comment #16) > (In reply to comment #15) > > Some points I'd really want to keep: > > - check in pkg_setup, so the user doesn't waste his compile time > > - fatal check, so the user really notices it > > How are they wasting their compile time? The package is perfectly functional > once they've unbroke their /etc/fstab, it doesn't harm compile nor the end > result of it in any way. > > > I'm sorry, but the argument about the users having broken /dev/shm setup and an > > entry in /etc/fstab doesn't reflect reality. > > Hmmm, try something like - well, anything that uses pulseaudio without /dev/shm > mounted. Yeah, it doesn't work. You want to add the same check to all ebuilds > that have pulseaudio in IUSE or happen to use pulseaudio in some way? > > > Again, if you have a patch that would make building it in a chroot or whatever > > easier, I'm open to use it provided it doesn't violate any of the important > > points above. > > The only patch that makes sense here it to make chromium spit out "uncomment > the darned /dev/shm line in fstab which has been needed since glibc-2.2 and you > shouldn't have messed with it in the first place" at runtime. Why doesn't > upstream provide any such message and instead leaves people with a browser that > doesn't render any webpage? > Perhaps a comment in /etc/fstab like: #do not comment or remove the shm entry. It is needed for some applications like www-client/chromium. How do you like this idea? Perhaps something else?
(In reply to comment #17) > Perhaps a comment in /etc/fstab like: > > #do not comment or remove the shm entry. It is needed for some applications > like www-client/chromium. > > How do you like this idea? Perhaps something else? I have already quoted vanilla Gentoo /etc/fstab in Comment #10. I don't understand WTH do people feel like messing with that line, this is something that should not be checked in totally unrelated ebuilds. Any application that uses shm_open() and shm_unlink() will fail when you break /etc/fstab like this, and once again "these functions are provided in glibc 2.2 and later" - from man shm_open(3)
Sorry Doktor Notor, Must have missed this when I checked my fstab prior to writing my comment. Agreed, it is a matter of simply reading the fstab during install and realising not to delete or comment the line. I am not sure why I did!? Still, the reputation of gentoo mentioned earlier I think also has *some* merit, but gentoo is not meant to be an install and walk-away distro and in my opinion, the project does not allow itself to frivolously follow external forces. Perhaps this issue should be simply forgotten and seen as my and others' fault.
Well, I'd understand if sys-lib/glibc ebuilds were checking for this somewhere is pkg_postinst and would spit out some message for the user, but why do this in chromium or whatever other application?
(In reply to comment #20) > Well, I'd understand if sys-lib/glibc ebuilds were checking for this somewhere > is pkg_postinst and would spit out some message for the user, but why do this > in chromium or whatever other application? > Agreed. I think this is what is needed to be done.
Filed Bug 308633 about wrong documentation in gentoo installation handbook.
