SPEC URL: https://spot.fedorapeople.org/chromium.spec
SRPM URL: https://spot.fedorapeople.org/chromium-45.0.2454.101-1.fc23.src.rpm

That spec is now cleaned up. In the process of making 45.0.2454.101, upstream jumped to 46, so I'm going to go start working on that now. Sigh. If the dependent reviews are somehow finished before that happens, we can review on 45.

SPEC URL: https://spot.fedorapeople.org/chromium.spec
SRPM URL: https://spot.fedorapeople.org/chromium-46.0.2490.71-1.fc23.src.rpm

So I just took a quick look at the spec, and I'm curious about this:

""""""""""""""
# Once upon a time, we tried to split these out... but that's not worth the effort anymore.
Provides:	chromium-ffmpegsumo = %{version}-%{release}
Obsoletes:	chromium-ffmpegsumo <= 35.0.1916.114
""""""""""""""

What's this about? Don't we need this split out as a subpackage so that the component can be replaced by "The Other Repo" for those who want the expanded codec support and can legally have it?

(In reply to Neal Gompa from comment #3)
> So I just took a quick look at the spec, and I'm curious about this:
> 
> """"""""""""""
> # Once upon a time, we tried to split these out... but that's not worth the
> effort anymore.
> Provides:	chromium-ffmpegsumo = %{version}-%{release}
> Obsoletes:	chromium-ffmpegsumo <= 35.0.1916.114
> """"""""""""""
> 
> What's this about? Don't we need this split out as a subpackage so that the
> component can be replaced by "The Other Repo" for those who want the
> expanded codec support and can legally have it?

A couple of reasons:

1. Google forked the ffmpeg codebase a while ago, so stock ffmpeg is no longer a standalone replacement.
2. Chromium's codebase now compiles the ffmpegsumo (their fork) into the chromium binary. It might be possible to hack it to generate that shared library again, but I have not had the time/motivation, since most people who want those extra codecs seem to just use Google Chrome.

SPEC URL: https://spot.fedorapeople.org/chromium.spec
SRPM URL: https://spot.fedorapeople.org/chromium-46.0.2490.80-1.fc23.src.rpm

@Tom: I think it would be valuable to split ffmpegsumo back out, if it's possible.

From what I've observed, the usage of Chrome is pretty much because we don't provide Chromium. I think it would be a disservice to our users to not provide them a capability to enhance Chromium for their needs and force them to use Chrome when all they want to do is just have more codecs supported.

My hope is that such a thing won't have to last too long, as Samsung appears to be working rather hard on implementing a fully functional GStreamer backend in Chromium[0]. I hope it gets to a merge-able state soon and the Chromium guys accept it.

[0]: https://github.com/Samsung/ChromiumGStreamerBackend

It looks like they (Chromium upstream) gutted all of their stub generation code for loading shared library dependencies like ffmpegsumo. I'm not comfortable carrying that patchset indefinitely to support this case. If you really want this, I'd recommend you open a bug with upstream Chromium to have it re-enabled as a gyp define/option.

It doesn't appear to be that way. I've seen SUSE and Ubuntu pull this off, while Mageia goes a step further and makes it work with the system ffmpeg.

SUSE's version of the chromium browser is at 46.0.2490.71, and creates a chromium-ffmpegsumo subpackage[0]. It appears that this approach requires -Dbuild_ffmpegsumo=1 and -Dcomponent=shared_library. This approach was also taken by Ubuntu in their build of chromium 45.0.2454.101[1].


Mageia's version of the chromium browser is at 46.0.2490.80, and uses the system copy of ffmpeg with some patches[2][3].

[0]: https://build.opensuse.org/package/view_file/openSUSE:Factory/chromium/chromium.spec?expand=1

[1]: http://archive.ubuntu.com/ubuntu/pool/universe/c/chromium-browser/chromium-browser_45.0.2454.101-0ubuntu1.1201.debian.tar.xz (look in debian/rules)

[2]: http://svnweb.mageia.org/packages/cauldron/chromium-browser-stable/current/SPECS/chromium-browser-stable.spec?view=markup

[3]: http://svnweb.mageia.org/packages/cauldron/chromium-browser-stable/current/SOURCES/

New SRPM: https://spot.fedorapeople.org/chromium-46.0.2490.80-2.fc23.src.rpm
New SPEC: https://spot.fedorapeople.org/chromium.spec

I didn't put the "clean" ffmpegsumo in a subpackage, because at this point, it is the only option for chromium, however, it would be relatively straightforward to do so, add a virtual provides for that subpackage, then have the base chromium package depend on that. Then, if someone were to create a chromium-ffmpegsumo-with-mpeg, they could.

(In reply to Neal Gompa from comment #6)
> From what I've observed, the usage of Chrome is pretty much because we don't
> provide Chromium.

That's just your notion. Google provides RPMs for i386 while this chromium only has ExclusiveArch x86_64.

(In reply to Christopher Meng from comment #10)
> (In reply to Neal Gompa from comment #6)
> > From what I've observed, the usage of Chrome is pretty much because we don't
> > provide Chromium.
> 
> That's just your notion. Google provides RPMs for i386 while this chromium
> only has ExclusiveArch x86_64.

Enabling support for i386 is incredibly painful, though, now that there is support for shared library components again, possibly less so. The biggest issue will be getting the nacl/pnacl toolchains working on i386. I wonder whether the 6 people still using ia32-only hardware even care.

(In reply to Tom "spot" Callaway from comment #11)
> (In reply to Christopher Meng from comment #10)
> > (In reply to Neal Gompa from comment #6)
> > > From what I've observed, the usage of Chrome is pretty much because we don't
> > > provide Chromium.
> > 
> > That's just your notion. Google provides RPMs for i386 while this chromium
> > only has ExclusiveArch x86_64.
> 
> Enabling support for i386 is incredibly painful, though, now that there is
> support for shared library components again, possibly less so. The biggest
> issue will be getting the nacl/pnacl toolchains working on i386. I wonder
> whether the 6 people still using ia32-only hardware even care.

You won't need to care about i686 after CentOS 6/7 reaching their EOL. Now the fact is, vendor doesn't want to support ix86 while increasing the burden to downstream. I have to say I agree with Red Hat's decision but also big thanks to Google to let me still have ability to enjoy the Internet without Mozilla crapfox.

NaCl is a serious issue indeed, I'm not sure if Fedora has loosened the guideline, but it's a blocker of this package, and solving this is not easy.

Rather than try to wrangle with nacl for i686, I've simply disabled native_client support in chromium for that architecture, and added i686 to the ExclusiveArch list.

New SRPM: https://spot.fedorapeople.org/chromium-46.0.2490.80-5.fc23.src.rpm
New SPEC: https://spot.fedorapeople.org/chromium.spec

I'm doing builds of this for i686 and x86_64 in my copr (https://copr.fedoraproject.org/coprs/spot/chromium/build/131554/). I would greatly appreciate some i686 testing, as I haven't had any ia32 hardware in a very long time.

hi
amazing work
have tired to use libphonenumber-7.1.1 https://bugzilla.redhat.com/show_bug.cgi?id=1200115 istead of bundled(libphonenumber) = svn584 ?

sorry, i meant tried

(In reply to gil cattaneo from comment #14)
> hi
> amazing work
> have tired to use libphonenumber-7.1.1
> https://bugzilla.redhat.com/show_bug.cgi?id=1200115 istead of
> bundled(libphonenumber) = svn584 ?

No, because upstream does not currently consider that a component that can be supported by a system library version. This is true for most of the components that are made by google that chromium uses (e.g. skia).

At the risk of adding a complication that isn't quite ready yet: Chromium supports u2f tokens, but it won't work due to permission issues out of the box.  Would it make sense to add Requires: u2f-hidraw-policy so that u2f just works?

u2f-hidraw-policy is currently hanging out in updates-testing waiting for non-anonymous karma on f23 :(  It'll be in updates for real before chromium hits updates, though.

(In reply to Andy Lutomirski from comment #17)
> At the risk of adding a complication that isn't quite ready yet: Chromium
> supports u2f tokens, but it won't work due to permission issues out of the
> box.  Would it make sense to add Requires: u2f-hidraw-policy so that u2f
> just works?
> 
> u2f-hidraw-policy is currently hanging out in updates-testing waiting for
> non-anonymous karma on f23 :(  It'll be in updates for real before chromium
> hits updates, though.

I don't mind doing this, but I want to wait for it to hit updates-stable before I do. I'm still pushing this SRPM through copr while it waits (indefinitely) for it and all of its dependencies (and bugfixes) to be resolved. Please just poke here again when u2f-hidraw-policy is done.

It will be great to have chromium-remote-desktop subpackage as its sources are in the same chromium-46.0.2490.80.tar.xz as chromium itself(in remoting folder).

See
https://chromium.googlesource.com/chromium/src/+/master/docs/chromoting_build_instructions.md

https://code.google.com/p/chromium/issues/detail?id=343329

u2f-hidraw-policy is now in f22 and f23 stable.

How Nvidia breaks Chrome Incognito

https://charliehorse55.wordpress.com/2016/01/09/how-nvidia-breaks-chrome-incognito/

Sorry if that's offtopic to the review in general, but it's IMHO a security issue also possibly dedicated to chromium.

(In reply to Raphael Groner from comment #21)
> How Nvidia breaks Chrome Incognito
> 
> https://charliehorse55.wordpress.com/2016/01/09/how-nvidia-breaks-chrome-
> incognito/
> 
> Sorry if that's offtopic to the review in general, but it's IMHO a security
> issue also possibly dedicated to chromium.

This seems to be a driver issue - as that article says. So I don't see any relationship to chrome/chromium.

(In reply to Heiko Adams from comment #22)
> (In reply to Raphael Groner from comment #21)
> > How Nvidia breaks Chrome Incognito
> > 
> > https://charliehorse55.wordpress.com/2016/01/09/how-nvidia-breaks-chrome-
> > incognito/
> > 
> > Sorry if that's offtopic to the review in general, but it's IMHO a security
> > issue also possibly dedicated to chromium.
> 
> This seems to be a driver issue - as that article says. So I don't see any
> relationship to chrome/chromium.

Yes. Similiar issue could happen with any other application, too. That's no issue with our general review, please continue.

New SRPM: https://spot.fedorapeople.org/chromium-48.0.2564.116-3.fc24.src.rpm
New SPEC: https://spot.fedorapeople.org/chromium.spec

Adds chrome-remote-desktop subpackage, Requires: u2f-hidraw-policy.

@Tom, 

I see this bit in the spec:

> %if 0
> # see https://code.google.com/p/chromium/issues/detail?id=501318
> BuildRequires:	libsrtp-devel >= 1.4.4
> %endif

The conditional looks like it would always be false, is this intentional? Or is the complete conditional missing?

Sorry to be slightly off-topic: the last upgrade of re2 from 20131024-5.fc23.x86_64 to 20160401-2.fc23.x86_64 in the COPR repository makes Chromim crash. Where can I report it?

You can either rollback re2 to the previous release or wait for this build to finish in the copr:

https://copr.fedorainfracloud.org/coprs/spot/chromium/build/182130/

(In reply to Tom "spot" Callaway from comment #27)
> You can either rollback re2 to the previous release or wait for this build
> to finish in the copr:
> 
> https://copr.fedorainfracloud.org/coprs/spot/chromium/build/182130/

Thanks Tom. I tried build 182133 and it gave me another crash, different from the previous one though.

(In reply to Jorge Martínez López from comment #28)
> (In reply to Tom "spot" Callaway from comment #27)
> > You can either rollback re2 to the previous release or wait for this build
> > to finish in the copr:
> > 
> > https://copr.fedorainfracloud.org/coprs/spot/chromium/build/182130/
> 
> Thanks Tom. I tried build 182133 and it gave me another crash, different
> from the previous one though.

Is it stack-smashing around libcontent?

======= Backtrace: =========
/lib64/libc.so.6(+0x7ac27)[0x7f8f33c9cc27]
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f8f33d3f317]
/lib64/libc.so.6(__fortify_fail+0x0)[0x7f8f33d3f2e0]
/usr/lib64/chromium-browser/lib/libgpu.so(+0xe878b)[0x7f8f40ccc78b]
/usr/lib64/chromium-browser/lib/libgpu.so(+0xec3e4)[0x7f8f40cd03e4]
/usr/lib64/chromium-browser/lib/libgpu.so(_ZN3gpu14GpuControlList12MakeDecisionENS0_6OsTypeENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_7GPUInfoE+0x218)[0x7f8f40cd0778]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate19UpdateGpuInfoHelperEv+0x18d)[0x7f8f43fdd55d]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate12SetGLStringsERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_S8_+0x8b7)[0x7f8f43fdea27]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate14InitializeImplERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_RKN3gpu7GPUInfoE+0x2f6)[0x7f8f43fded56]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate10InitializeEv+0x221)[0x7f8f43fdf191]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content18GpuDataManagerImpl10InitializeEv+0x1e)[0x7f8f43fd69ce]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content15BrowserMainLoop16PreCreateThreadsEv+0xcd)[0x7f8f43ed2f4d]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content17StartupTaskRunner14RunAllTasksNowEv+0x2f)[0x7f8f441a968f]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content15BrowserMainLoop18CreateStartupTasksEv+0x8a)[0x7f8f43ed7b4a]
/usr/lib64/chromium-browser/lib/libcontent.so(+0x59ea79)[0x7f8f43ed9a79]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content11BrowserMainERKNS_18MainFunctionParamsE+0xb3)[0x7f8f43ed1c13]
/usr/lib64/chromium-browser/lib/libcontent.so(+0x50fb74)[0x7f8f43e4ab74]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content11ContentMainERKNS_17ContentMainParamsE+0x41)[0x7f8f43e49f41]
/usr/lib64/chromium-browser/chromium-browser(+0x49338a)[0x5610cd31f38a]
/lib64/libc.so.6(__libc_start_main+0xf1)[0x7f8f33c42721]
/usr/lib64/chromium-browser/chromium-browser(+0x49324a)[0x5610cd31f24a]

If so, that's concerning. I thought that might just be GCC 6 on F24. :/

(In reply to Tom "spot" Callaway from comment #29)
> (In reply to Jorge Martínez López from comment #28)
> > (In reply to Tom "spot" Callaway from comment #27)
> > > You can either rollback re2 to the previous release or wait for this build
> > > to finish in the copr:
> > > 
> > > https://copr.fedorainfracloud.org/coprs/spot/chromium/build/182130/
> > 
> > Thanks Tom. I tried build 182133 and it gave me another crash, different
> > from the previous one though.
> 
> Is it stack-smashing around libcontent?
> 
[...]
> If so, that's concerning. I thought that might just be GCC 6 on F24. :/

Yes, that's the one:

$ chromium-browser --disable-extensions --disable-plugins
[19580:19580:0430/215149:VERBOSE1:breakpad_linux.cc(1838)] Breakpad disabled
[1:1:0430/215150:VERBOSE1:zygote_main_linux.cc(565)] ZygoteMain: initializing 2 fork delegates
[1:1:0430/215150:VERBOSE1:nacl_fork_delegate_linux.cc(145)] NaClForkDelegate::Init()
[1:1:0430/215150:VERBOSE1:nacl_fork_delegate_linux.cc(145)] NaClForkDelegate::Init()
[1:1:0430/215150:INFO:systeminfo.cc(82)] Available number of cores: 6
*** stack smashing detected ***: /usr/lib64/chromium-browser/chromium-browser --enable-plugins --enable-extensions --enable-user-scripts --enable-printing --enable-sync --auto-ssl-client-auth --enable-logging=stderr --v=2 --disable-extensions --disable-plugins terminated
======= Backtrace: =========
/lib64/libc.so.6(+0x77da5)[0x7ff9823cfda5]
/lib64/libc.so.6(__fortify_fail+0x37)[0x7ff98246c5b7]
/lib64/libc.so.6(__fortify_fail+0x0)[0x7ff98246c580]
/usr/lib64/chromium-browser/lib/libgpu.so(+0xe9a1b)[0x7ff98f487a1b]
/usr/lib64/chromium-browser/lib/libgpu.so(+0xed693)[0x7ff98f48b693]
/usr/lib64/chromium-browser/lib/libgpu.so(_ZN3gpu14GpuControlList12MakeDecisionENS0_6OsTypeENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKNS_7GPUInfoE+0x21c)[0x7ff98f48b9cc]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate19UpdateGpuInfoHelperEv+0x105)[0x7ff992866195]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate12SetGLStringsERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_S8_+0x8b7)[0x7ff992867647]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate14InitializeImplERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_RKN3gpu7GPUInfoE+0x2f6)[0x7ff992867976]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content25GpuDataManagerImplPrivate10InitializeEv+0x221)[0x7ff992867db1]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content18GpuDataManagerImpl10InitializeEv+0x1e)[0x7ff99285f79e]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content15BrowserMainLoop16PreCreateThreadsEv+0xcd)[0x7ff99275f8ad]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content17StartupTaskRunner14RunAllTasksNowEv+0x2f)[0x7ff992a300bf]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content15BrowserMainLoop18CreateStartupTasksEv+0x8a)[0x7ff9927644ca]
/usr/lib64/chromium-browser/lib/libcontent.so(+0x66a4f9)[0x7ff9927664f9]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content11BrowserMainERKNS_18MainFunctionParamsE+0xb3)[0x7ff99275e1a3]
/usr/lib64/chromium-browser/lib/libcontent.so(+0x5db0f4)[0x7ff9926d70f4]
/usr/lib64/chromium-browser/lib/libcontent.so(_ZN7content11ContentMainERKNS_17ContentMainParamsE+0x41)[0x7ff9926d6521]
/usr/lib64/chromium-browser/chromium-browser --enable-plugins --enable-extensions --enable-user-scripts --enable-printing --enable-sync --auto-ssl-client-auth --enable-logging=stderr --v=2 --disable-extensions --disable-plugins(+0x4af4ea)[0x55db170364ea]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7ff982378580]
/usr/lib64/chromium-browser/chromium-browser --enable-plugins --enable-extensions --enable-user-scripts --enable-printing --enable-sync --auto-ssl-client-auth --enable-logging=stderr --v=2 --disable-extensions --disable-plugins(+0x4af3a9)[0x55db170363a9]

*sigh* Okay. I'm doing a debugging build locally now to try to figure out what's breaking this. I'll try to look at it some more this weekend, but I make no promises. :/

Jorge, are you running Fedora 23 or 24?

(In reply to Tom "spot" Callaway from comment #32)
> Jorge, are you running Fedora 23 or 24?

23 x86_64.

Okay, this is filed upstream:
https://bugs.chromium.org/p/chromium/issues/detail?id=608205

If anyone on CC here has experience in debugging stack smashing, I would appreciate help. I tried, and all I got was that Chromium calls libgpu a LOT during startup.

Any interest in moving to using "gn" for builds? I notice this rpm package still uses "gyp."

I ask because of these posts to the packaging mailing list: "We're going to start shutting off GYP soon"

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/YK-Qm3wRcio

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-packagers/hGUmlE1yAoo

Cheers.

(In reply to Gary Gatling from comment #35)

*sigh*. Patches or liquor accepted.

Lemme get a working build first, then I'll see about gn.

Are you subscribed to chromium-packagers? It's a few messages per month and is the primary announce/discussion list for downstream distributions.

https://groups.google.com/a/chromium.org/forum/#!forum/chromium-packagers

Strongly recommend subscription if you haven't already.

(In reply to Adam Goode from comment #37)
> Are you subscribed to chromium-packagers? It's a few messages per month and
> is the primary announce/discussion list for downstream distributions.
> 
> https://groups.google.com/a/chromium.org/forum/#!forum/chromium-packagers
> 
> Strongly recommend subscription if you haven't already.

I am.

I just had put off "port to YET ANOTHER BUILD TOOL" for a later date. Looking at the Gentoo ebuild, it looks like they've figured out most/all of the changes, so I think it shouldn't be too ugly (famous last words).

Ok, let me know if you need help with patches for Chromium stuff. I've done a few recently for fixes with use_sysroot=false:

https://codereview.chromium.org/1699713002/
https://codereview.chromium.org/1671203002/

(In reply to Tom "spot" Callaway from comment #36)
> *sigh*. Patches or liquor accepted.
> 
> Lemme get a working build first, then I'll see about gn.

I will do the work as I should have a branch somewhere with the work around GN that I've done around Christmas time..

Also I should note, that the status of the GN is not that great for building with out of tree builds (from tarballs) as you can see in [0]. Actually it was the reason why I didn't complete the previous work and it seems that the situation didn't changed a lot..

[0] - https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/3NAXifb84dk

(In reply to Tom "spot" Callaway from comment #34)
> Okay, this is filed upstream:
> https://bugs.chromium.org/p/chromium/issues/detail?id=608205

Did the re2 issue ever get fixed?  I have chromium-48.0.2564.116-2.fc23.x86_64 from your https://repos.fedorapeople.org/repos/spot/chromium-stable/ repo and still experience it.  In the meantime, I'll try to downgrade re2.

re2-20131024-5.fc23.x86_64 resolves the chromium-48.0.2564.116-2.fc23.x86_64 crash for now.  (re2-20160401-2.fc23.x86_64 caused crash on startup.)

I'm pushing new packages to the "old" stable repo now that will work with the new re2 package update. The copr already has those builds.

The package in the copr repo is still pretty crashy.  In fact, I can't get it to load any pages (on a new F24 install, clean $HOME) with seeing the "Aw, Snap" crash.  Is that expected with the copr repo?

FYI, the link to the Copr repo is broken on this page:
https://fedoraproject.org/wiki/Chromium

Yep, Chromium in F24 is pretty much broken, I see the pages loading and upon finishing I get the "Aw, snap" page. I managed to rescue this trace but I don't think it's very informative:

[1:1:0621/210853:VERBOSE1:script_context.cc(111)] Created context:
  extension id:           (none)
  frame:                  (nil)
  URL:                    
  context_type:           UNSPECIFIED
  effective extension id: (none)
  effective context type: UNSPECIFIED
[1:1:0621/210853:VERBOSE1:dispatcher.cc(333)] Num tracked contexts: 4
[1:1:0621/210853:VERBOSE1:script_context.cc(118)] Destroyed context for extension
  extension id: 
  effective extension id: 
[1:1:0621/210853:VERBOSE1:script_context.cc(118)] Destroyed context for extension
  extension id: 
  effective extension id: 
[1:1:0621/210853:VERBOSE1:script_context.cc(118)] Destroyed context for extension
  extension id: 
  effective extension id: 
[1:1:0621/210853:VERBOSE1:script_context.cc(118)] Destroyed context for extension
  extension id: 
  effective extension id: 
Received signal 11 SEGV_MAPERR 000000000008
#0 0x7f4afd5dc4ae base::debug::StackTrace::StackTrace()
#1 0x7f4afd5dc8bb <unknown>
#2 0x7f4aecc2ec30 <unknown>
#3 0x7f4aeec7a0e0 <unknown>
#4 0x7f4aeec7a317 <unknown>
#5 0x7f4aeec7a5c1 <unknown>
#6 0x7f4aeec6c6fc <unknown>
#7 0x7f4aeec284c5 <unknown>
#8 0x7f4aeed1e804 <unknown>
#9 0x7f4aeed3bcf1 <unknown>
#10 0x7f4aeed427a1 <unknown>
#11 0x7f4aeed42ad6 <unknown>
#12 0x7f4aeed61e17 <unknown>
#13 0x7f4aeed0c71d <unknown>
#14 0x7f4aeed49f68 <unknown>
#15 0x7f4aeed56682 <unknown>
#16 0x7f4aeecc8997 <unknown>
#17 0x7f4aeeccb292 <unknown>
#18 0x158bed40961b <unknown>
  r8: 00000000ffffffff  r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000246
 r12: 00000419a3c6a310 r13: 0000000000000000 r14: 00007f4aef337e38 r15: 00000419a3c48020
  di: 00000419a3c48be0  si: 00000419a3bbe440  bp: 00000419a3bf3000  bx: 00000419a3bef1b0
  dx: 00000419a3c48cb0  ax: 0000000000000000  cx: 000020d755300000  sp: 00007ffeafbacb90
  ip: 00007f4aeec7a0e0 efl: 0000000000010246 cgf: 0000000000000033 erf: 0000000000000006
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008
[end of stack trace]

Same here; also, plugins such as uBlock Origin and HTTPS Everywhere seem to crash on loading.

Same problem in my case.
It may be an issue with some of the changes made by the packager, since the official chrome provided by google runs fine. If I get the time I will build a vanilla chromium using the instructions at https://www.chromium.org/developers/how-tos/get-the-code and post if it worked.

I ran into this problem with a chromium I built. If I ran the fedora 23 binary on fedora 24 it worked. If I ran the fedora 24 binary it crashed with a "Aw, snap" after pretty much every page load.

Similar experience to Gary - as a workaround I'm  running the fedora23 binaries ( chromium-50.0.2661.94-6.fc23.x86_64 and chromium-libs ) from repo fedora-chromium-stable on my two fedora24 boxes without problems.

I have various plugins enabled including HTTPS-Everywhere, Privacy Badger - all running fine.

No surprise - the fedora24 binaries aren't too happy for me either - hitting the crash in libgpu.so

As I side-note I see that the fedora24 binary from fedora-chromium-stable is relatively old ( chromium-48.0.2564.116-2.fc24.x86_64.rpm) vs what's in there for fedora23 that I currently have installed.

spot, mind giving a fresh/updated spec/srpm urls?

I strongly suspect the links from comment #5 aren't current anymore.

This?
https://spot.fedorapeople.org/chromium-52.0.2743.60-1.fc24.src.rpm


zbyszek, I see the review is assigned to you, but you haven't commented in ~2 months, do you want to continue with the review?
(Else, I'd be happy to help pick things up)

You can review off that SRPM. It's technically not a stable release of Chromium (it's in their "beta" tag at the moment), but since 51 doesn't work right at all with Fedora 24, I had to push something.

I've also had to disable nacl/pnacl support for Fedora 24, because I still haven't gotten the newer native_client bits to build cleanly from sources there. I'm sorely tempted to just leave nacl/pnacl disabled in Fedora. If anyone has an opinion on that, speak up.

If native_client isn't required currently, I'll focus on chromium(here) for now.

Thanks, and I'll use recent copr build:
https://copr.fedorainfracloud.org/coprs/spot/chromium/build/375281/

for reference.  note build fails on rawhide apparently due to some api differences in rawhide's cups-2.2-0.1b2 (compared to f24's cups-2.1.4), but I won't consider that a review blocker (though it should get addressed in due course)

Naming: ok

Licensing: ok
1. SHOULD: can you confirm that OpenSSL is still needed?  during review of qtwebengine (which bundles chromium), we determined that (only) nss was used there.

sources: ok
kinda have to take your word for it here, as the source generation is scripted to remove patented sources (and possibly not 100% reproducible)

scriptlets: ok

macros: ok

file/directory ownership: ok

2. SHOULD consider %lang'ifying
%{chromium_path}/locales/
content (or add a .spec comment why this is not possible or practical or whatever).

builds/installs/runs: ok

changelog format: ok

-debuginfo: ok
3.  SHOULD: good enough for now, thought it's current size of ~10mb makes me question whether the buildsystem may be stripping -g debug flags too aggressively to make the -debuginfo useful.

bundling: ok
another... good enough for now, given fedora' relaxed bundling policies, I think anything that can be reasonably unbundled is being done.

4.  SHOULD consider cleaning .spec of some deprecated tags, including:
BuildRoot:
Group:
%defattr
%clean

5.  SHOULD.  we found in qtwebengine, v8 code needed -fno-delete-null-pointer-checks to avoid some crashing, see also:
https://bugs.chromium.org/p/v8/issues/detail?id=3782
you might want to add that here too.


After looking things over closely, that's all I could come up with, which didn't actually include any blockers.  So, I'm happy to mark this APPROVED.  may the force be with you.

Package request has been approved: https://admin.fedoraproject.org/pkgdb/package/rpms/chromium

chromium-52.0.2743.82-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3a9adbe000

chromium-52.0.2743.82-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3a9adbe000

chromium-52.0.2743.82-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Can we remove the alias "chromium" from this bug report?
Every time I want to search bugs related to chromium, input "chromium" in the search field and click search, it always come here.

Alternative (and imo better) ways to search for bugs against a particular component include:

(my favorite)
http://bugz.fedoraproject.org/chromium

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&component=chromium&list_id=6427970&product=Fedora