Comments

106 Comments

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

karma

Loads STL files and slices them.

BZ#1779297 prusa-slicer-2.2.0 is available
BZ#1799898 prusa-slicer: FTBFS in Fedora rawhide/f32

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

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