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

@axiomatic: please make sure you update all of the texlive packages, especially texlive-kpathsea. If you still have an issue after all of the texlive packages in this update are updated, please open a new bugzilla report!

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.

robbiethek: You have to wait for this update to get pushed again. Note that the version in your output is "7:20200327-16.fc32".

robbiethek: new texlive-base builds coming now that should fix that.

Okay, GDK_SCALE works again for me with -3. Please test one more time.

Maybe, but then again, no.

I'm about to push updates for 83.0.4103.116 into bodhi, which will supercede this one (and inherit it). I think I figured out what I did that broke the behavior, but please test and let me know.

Never mind, I see my typo now and have reproduced. :/

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.

Hmmmm. Okay. Is this in Wayland or Xorg?

Did GDK_SCALE= work before? Does it work in Google Chrome?

Loads STL files and slices them.

That's fine. The latest 78 build has the chrome store bug fixed.

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

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

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