sumomo, your bug is legitimate, but I don't think it is in chromium, but rather, minizip. I can reproduce this, but only on EL8, and the build is identical to Fedora here. This bug is also present in the chromium 78 epel8 build I just tested. Debugging this is rather confusing, since it dies after mz_stream_create.
I opened a bug against minizip on this (before the bugzilla server went on maintenance this morning).
quantumcheese: I totally understand. Right now, the issue is that the epel6 buildroot does not include devtoolset, so I can't build R with it and properly generate Makeconf with CXX11 values. (Yes, I could do what you did and monkey patch them in, but then, I'll start getting build failure reports from random R modules when people try to build them with the system toolchain. This didn't fail like this before because R 3.6.0 is doing stricter checking on compiler functionality.
Also, it's not clear if EPEL6 will add devtoolset to the repo, since the EPEL6 repo is going to be end-of-lifed in 6 months. If they do, I can build it (the logic is added to the RPM now), but... do you have a CentOS 6 to 7 migration plan? :D
quantumcheese: We have never built R with the devtoolset toolchain, but rather, the stock EL toolchain, which I do not believe has full support for C++11. This leads to the Makeconf not having CXX11 references. If we build R for EL with devtoolset, it gets tricky, because then R package building will break for any users not using devtoolset.
I think that most users will want C++11 support (which many modern R packages depend on), so I'll just adjust the package to build with it and Requires it.
@pdestefa : The texlive-2016-48.20160520.fc28 package has a new texlive-fvextra subpackage, which Provides: tex(fvextra.sty). The texlive-base-20170520-38.fc28 package (which generates the texlive-pythontex subpackage) has been changed so that texlive-pythontex has an explicit Requires: tex(fvextra.sty).
Your log shows you upgrading texlive and texlive-base. Try upgrading texlive-pythontex (it should pull in texlive-fvextra as a dependency).
The error is caused by the transaction ordering. When you do a fresh install of the -2 package, there is no bug, but if you update to the -2 package from any previous chromium packages, you hit the bug. I put the alternatives handling in %post, but %post runs before the old package is removed (https://fedoraproject.org/wiki/Packaging:Scriptlets#Ordering). That means that the files like libffmpeg.so are still present from the old package, and the scriptlets fail. In the -3 package, I moved the alternatives scriptlets to %posttrans, so they run after the old package is completely gone, and this resolves the error. I confirmed that this fixes the issue with a rawhide build, builds for all other targets are going now, and when they finish, I'll put them in the update instead.
Please don't come and downvote this because you have chromium-libs-media-freeworld installed from rpmfusion. They requested this change, but haven't pushed out their part yet. See: https://bugzilla.rpmfusion.org/show_bug.cgi?id=4363
I don't think you can install any random i686 package on x86_64. dnf install firefox.i686 fails in the same way. I haven't done any magic to permit simultaneous installations, and I'm honestly not sure why you'd want the 32bit version...