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).

User Icon spot commented & provided feedback on R-3.6.1-1.el8, … 3 years ago

I left this as is, because EPEL-8 is brand new, and it makes sense for it to inherit this scheme (since we'll be supporting R packages here for several years to come).

User Icon spot commented & provided feedback on R-3.6.0-1.el6 3 years ago

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

User Icon spot commented & provided feedback on R-3.6.0-1.el6 3 years ago

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).

@rdieter, not sure there's a way to avoid that. It will be resolved if R is reinstalled (and I doubt anything in R is actually using those old latex files).

qulogic, thanks for the follow-up. Let's go ahead and let this update land, and do the others as a separate update.

R-COPASI did get rebuilt, but the maintainer put it into an update of its own (then, deleted it).

This update has been unpushed.

This update has been unpushed.

This update has been unpushed.

No. We cannot ship H264 support for legal reasons.

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 ( That means that the files like 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.

Thanks lupinix, I see the issue you're hitting now. Building -3 to remedy it.

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:

Never mind, I see the failure now.

Hmm. It is working for me on Fedora 25... are you sure you're on -7?

If you have a bug with Chromium, please file it. Leaving vague negative karma here is not terribly helpful.

I think the dependency issues are all resolved in -6.

Fixed in -2.

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...