@boycottsystemd1 - Your error looks very similar to an old bug: https://bugzilla.redhat.com/show_bug.cgi?id=1968318
Please ensure that you are running the latest kernel (and all updates) and retest. If it persists, please open a bugzilla for it, as it is much easier to track things there than in bodhi.
Finally, since it seems that --ozone-platform=wayland is triggering this bug for you, you can edit /usr/bin/chromium-browser and comment out line 55 as a temporary workaround.
I just brought up a fresh Fedora 32 VM, did a
dnf install --disablerepo=updates texlive-scheme-full (to get a ton of texlive bits installed from the original Fedora 32 tree), then when that finished, ran
dnf update --enablerepo=updates-testing, and that finished without errors.
robbiethek: Yes, this is what I would expect to see. Without enabling the "updates-testing" repo, dnf cannot find the fixed versions (texlive-2020-32.fc32 and texlive-base-20200327-18.fc32) and instead tries to install the older, broken versions. Once this update moves into stable, the fixed packages will land in the "updates" repo.
This is going to be difficult for me to troubleshoot, as I do not have a hiDPI monitor and GTK_SCALE does nothing for me without one. I need this update to go out to fix the serious security issues, so please open a bug to track this in bugzilla.
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).