‘Package XXX is not signed’ error during upgrade to Fedora 24

Many people hit issues like this when trying to upgrade to Fedora 24:

 Error: Package a52dec-0.7.4-19.fc24.x86_64.rpm is not signed

You can easily see that this is a very widespread issue if you look at comments section under our upgrade guide on fedora magazine. In fact, this issue probably affects everyone who has rpmfusion repository enabled (which is a very popular third-party repository). Usually the a52dec package is mentioned, because it’s early in the alphabet listing, but it can be a different one (depending on what you installed from rpmfusion).

The core issue is that even though their Fedora 24 repository is available, the packages in it are not signed yet – they simply did not have time to do that yet. However, rpmfusion repository metadata from Fedora 23 demand that all packages are signed (which is a good thing, package signing is crucial to prevent all kinds of nasty security attacks). The outcome is that DNF rejects the transaction for being unsecure.

According to rpmfusion maintainers, they are working on signing their repositories and it should be done hopefully soon. So if you’re not in a hurry with your upgrade, just wait a while and the problem will disappear soon (hopefully).

But, if you insist that you want to upgrade now, what are your options?

Some people suggest you can add --nogpgcheck option to the command line. Please don’t do that! That completely bypasses any security checks, even for proper Fedora packages! It will get you vulnerable to security attacks.

A much better option is to temporarily remove rpmfusion repositories:

$ sudo dnf remove 'rpmfusion-*-release'

and run the upgrade command again. You’ll likely need to add --allowerasing option, because it will probably want to remove some packages that you installed from rpmfusion (like vlc):

$ sudo dnf system-upgrade download --releasever=24 --allowerasing

This is OK, after you upgrade your system, you can enable rpmfusion repositories again, and install the packages that were removed prior to upgrade.

(I recommend to really remove rpmfusion repositories and not just disable them, because they manage their repos in a non-standard way, enabling and disabling their updates and updates-testing repos during the system lifecycle according to their needs, so it’s hard to know which repos to enable after the system upgrade – they are not the same as were enabled before the system upgrade. What they are doing is really rather ugly and it’s much better to perform a clean installation of their repos.)

After the system upgrade finishes, simply visit their website, install the repos again, and install any packages that you’re missing. This way, your upgrade was performed in a safe way. The packages installed from rpmfusion might still be installed unsafely (depending whether they manage to sign the repo by that time or not), but it’s much better than to upgrade your whole system unsafely.

To close this up, I’m sorry that people are hit by these complications, but it’s not something Fedora project can directly influence (except for banning third-party repos during system upgrades completely, or some similar drastic measure). This is in hands of those third-party repos. Hopefully lots of this pain will go away once we start using Flatpak.

‘Package XXX is not signed’ error during upgrade to Fedora 24

AMD Radeon R9 270 experience in Fedora 23

Two years ago I purchased AMD Radeon R9 270 graphics card and wrote about my experience in Fedora 20 and also experience in Fedora 21 (Rawhide at that time). I decided to post an update to this, especially after recent news of AMD and Ubuntu deprecating fglrx (catalyst) proprietary driver.

Overall, I have to say the opensource radeon driver made huge progress in the last two years, and I don’t regret my purchase at all. Quite the opposite, I believe I’ve made the best choice possible by picking AMD. Basically everything I complained about in the past got fixed or improved. The dynamic power management works without a glitch. None of the X11 rendering operations are slow anymore. Support for vendor fan speed profiles has been implemented, so my card it now completely silent. All desktop rendering glitches went away a long time ago. The regular daily desktop usage is completely perfect and issue free, and actually noticeably superior even to current intel driver (which was known for its stability and reliability). The intel driver regressed a lot in the last 6 months or so, when developers started rewriting some core parts, while radeon driver remains completely bug-free in my experience.

The situation is of course more interesting when it comes to gaming. There were large quality and performance leaps in the radeon driver. The driver gained support for OpenGL 4.1 and higher versions of OpenGL are expected to be implemented in the next months. That itself fixed a lot of games which refused to run before. Performance also went up significantly. On Fedora 20/21 I complained that Dota 2 ran with 5-10 FPS on low settings. Now I can play it on ultra settings with 80 FPS. Of course this is an extreme example, but it shows that things really improved a lot. It also helps that Fedora is very active in packaging latest graphics driver stack and we usually run on a very recent version of the driver (compared to e.g. Ubuntu, which is quite conservative in this).

I won’t claim that everything it top-notch, though. There are still a few games that don’t run or don’t run well enough. The performance is also not yet up to the catalyst speed. But for a person like me, who owns many indie titles from various bundles, plays a few selected AAA titles from time to time, and can reboot to Windows in the absolutely worst case, is the current situation actually very good. And it seems to be improving constantly. The radeon driver development team is very responsive and if you write a reasonable request or a bug report, they really try to implement it or fix it (for example they implemented GPU-based display scaling on my request).

If you are interested which titles run on my Radeon R9 270 and how well, I made a profile on opengamebenchmarks.org and benchmarked most of my Steam library. You can have a look at my benchmarked games.

dota2-fps
FPS benchmark for Dota 2 on Radeon R9 270

As you can see, many even very graphics intensive games run quite well. For example Witcher 2 is infamous for how slow the Linux port is (it’s emulated by a proprietary wrapper similar to Wine), yet I can play it between 40-60 FPS depending on graphics detail. I was quite surprised.

If you are into gaming, I encourage you to submit your game benchmarks as well, so that we have an easy way to see how individual graphics and graphics vendors perform in games on Linux. I recently packaged voglperf and glxosd for Fedora, so it should be easy for your to install these benchmarking tools.

After considering all of this, I don’t really mind that AMD is deprecating catalyst. I understand that there are still use cases for catalyst, but most of the times the radeon driver is now a serious (and often better) alternative. If this means that AMD team will free up their hands from maintaining catalyst and will be able to put more people into radeon driver development (or the catalyst replacement which they plan to have on top of the opensource amdgpu kernel driver), it’s a good message for majority of Linux users.

AMD Radeon R9 270 experience in Fedora 23

glxosd and voglperf now available for Fedora in COPR

For all our gaming enthusiasts, I packaged glxosd and voglperf for Fedora and you can find them in my COPR repositories: glxosd COPR and voglperf COPR.

These tools allow you to have FRAPS-like features on Linux, i.e. show an overlay in OpenGL games/apps to display current FPS, and also capture the frame times into a file and plot them to a graph later. So you can now use it with any Linux game and fine-tune its graphics settings to match your preferred performance. Or you can see when your CPU or GPU is overheating. Or you can contribute to Open Game Benchmarks. Or something else.

This is an example of the glxosd overlay in action (don’t worry, its output is configurable):

glxosd-chivalry.png
glxosd overlay

And if you want, you can later plot the performance into such pretty graphs using this awesome glxosd analyser web page:

glxosdGraph-fps.png
fps graph
glxosdGraph-frametimes.png
frame times graph

And this is an example of the voglperf overlay (top left corner):

voglperf-xcom.png
voglperf overlay

And a generated graph:

voglperf-frametimes.png
frame times graph

There are other similar tools which you can use, but I know about any that is generic and has all these features. There is of course the Steam FPS overlay, but you can only use it for Steam games, and it can’t log frame information. There’s also GALLIUM_HUD, but that’s only available for Gallium-enabled drivers (radeon, nouveau) and also can’t log frame information. These two new tools should work with any driver and can be used for any game/app.

You can find installation instructions in the linked COPR repos. I do not intend to move these packages to official Fedora repos, but if somebody is willing to get their hands dirty and work on that, great, please contact me and I’ll try to help.

Enjoy!

Flattr this

glxosd and voglperf now available for Fedora in COPR

Fedora videos from DevConf 2016 now available

145px-devconf-cz_logo

Even if you’ve been to DevConf personally, you surely missed a lot of very interesting talks and workshops. All the videos are now available. Here are the Fedora related ones:

https://www.youtube.com/playlist?list=PLU1vS0speL2YytY0-1oxuNWXmfd1BHSd6

And here is the full list:

https://www.youtube.com/playlist?list=PLjT7F8YwQhr-Ox8LZY8VFrZHFkApOduBi

Enjoy!

Fedora videos from DevConf 2016 now available

Git Tip of the Day – viewing diffs graphically with meld

I got tired of viewing diffs in a terminal with red and green text. I wanted to see diffs more comfortably, with syntax highlighting, segment highlighting (not just full lines), easy scrolling, searching, switching between files. I wanted to have something like Phabricator diff, Netbeans diff or PyCharm diff. So I finally spent 20 minutes (why do most annoyances take you 20 minutes to solve, but you delay them for years?) and found out that git now has a cool new command, git difftool. And it supports meld, a great graphical comparison program.

Let’s compare this:

clidiff
git diff in gnome-terminal

With this:

meld1
meld diff overview
meld2
meld file diff

Awesome, right?!! All you need to do is this:

$ git difftool --tool=meld -d <diffspec>

Option -d makes it work in directory mode, which works much better with meld. Of course this is too long to type every time, to let’s remember meld as the default diff tool, and even make an alias for it:

$ git config --global diff.tool meld
$ git config --global alias.dt 'difftool -d'

(Also, don’t forget to enable syntax highlighting in meld preferences, it was disabled for me for some reason.)

And now, voila:

$ git dt master..develop

I’m very happy about the increased readability and productivity.

 

Flattr this

Git Tip of the Day – viewing diffs graphically with meld

GPU resolution scaling on external monitors with open source drivers

Linux seems to be finally becoming a viable gaming platform. That brings us into uncharted territories and we start to discover some deficiencies which were solved on other platforms a long time ago. One of those is GPU-based screen scaling.

What is GPU-based screen scaling?

If you want to display a non-native (lower) resolution on your monitor, you have several options how to do that:

  1. Center image – Display the image in the center using 1:1 pixel mapping (one pixel from the image is 1 pixel on the screen). Add black bars from all 4 sides to fill the rest of the screen. This produces smaller but perfectly sharp image.
  2. Scale image while keeping aspect ratio – Enlarge the image as much as possible, and (if the image has a different aspect ratio than the monitor) add black bars from the remaining 2 sides (usually top and bottom for movies, left and right for old games). This produces large but blurrier image.
  3. Scale image fully ignoring aspect ratio – Simply fill the whole screen. This produces full-sized, but blurrier and distorted image (e.g. text is stretched, human bodies have incorrect proportions, etc).

Some of this can be configured through your external monitor’s OSD menu. Centered image is usually not available, and aspect-based scaling is often available only for certain resolutions. Full scaling seems to be (sadly) both the default and the only option available in many cases. Because I’ve just recently bought a new monitor, I investigated a bit and even pricier monitors more often than not offer only the described limited set of options. That is of course unfortunate.

For that reason (and also to be able to configure scaling for fixed notebook screens), graphical drivers offer options to scale the image for you, any way you like. Instead of the monitor, the graphics card does it. This allows you to use any scaling mode that fits your purpose, not just those implemented by the manufacturer of your monitor.

Why do I need screen scaling?

I have described some reasons here. Usually it’s because of either old games (wrong aspect ratio) or too modern games (your hardware doesn’t keep up).

How can I configure GPU-based screen scaling?

For fixed notebook screens, you can do that through xrandr. See the properties of your monitor:

$ xrandr --prop
Screen 0: minimum 320 x 200, current 1920 x 1968, maximum 8192 x 8192
LVDS1 connected 1366x768+289+1200 (normal left inverted right x axis y axis) 277mm x 156mm
    <snip>
    BACKLIGHT: 11 
        range: (0, 15)
    Backlight: 11 
        range: (0, 15)
    scaling mode: Full aspect 
        supported: None, Full, Center, Full aspect
   1366x768      60.10*+
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94

The default seems to be Full aspect. If you set None, it means the image should be sent unaltered into your monitor. You can configure different scaling like this:

$ xrandr --output LVDS1 --set "scaling mode" "Center"

This setting seems to be reset on machine reboot, and I haven’t investigated how to keep it permanent yet. Also, I tested this just on Intel, but I assume all drivers should support it.

For external monitors, I have a bad news for you – you can’t do it (yet). This is the deficiency I was talking about. The properties are not visible through xrandr. The proprietary AMD and NVIDIA drivers have supported it for a long time (example), but it seems there haven’t been enough demand in open source drivers yet (at least intel and radeon drivers can’t do it, I haven’t tested nouveau). So, I requested this functionality as Freedesktop bug 80868 and to my surprise there’s a tentative patch already (thanks Alex Deucher). If you’re skilled with C and hardware development, any help would be highly welcome. IIUIC, the patch will enable this functionality only for radeon driver – there will need to be a similar patch for intel (and possibly nouveau) driver.

 

Flattr this

GPU resolution scaling on external monitors with open source drivers