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.

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, … a year 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 a year 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 a year 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).

@rdieter, not sure there's a way to avoid that. It will be resolved if R is reinstalled (and I doubt anything in R is actually using those old latex files).

qulogic, thanks for the follow-up. Let's go ahead and let this update land, and do the others as a separate update.

R-COPASI did get rebuilt, but the maintainer put it into an update of its own (then, deleted it).

This update has been unpushed.

This update has been unpushed.

This update has been unpushed.

No. We cannot ship H264 support for legal reasons.