... 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?
/me throws his hands up in the air, just can't win