/me throws his hands up in the air, just can't win

... and thats why I waived it. My change literally symlinked a directory that made an obscure build tool that boost makes work. There is almost a 0% chance what I did is related to the failure, and it was blocking my package which depends on that build tool.

You need to update libwayland-client ... because it was in the buildroot for Chromium, it picked up the new symbols from the 1.20.0 update.

I believe this is the same unresolved issue from the previous chromium build with your specific configuration (which affects Google Chrome as well). If you comment out this line in /usr/bin/chromium-browser:

CHROMIUM_DISTRO_FLAGS="--ozone-platform=wayland $CHROMIUM_DISTRO_FLAGS"

Does the issue go away?

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