If you submit a new Fedora update into Bodhi, you’ll see an Automated Tests tab on that update page (an example), and one of the test results (once it’s done) will be from rpmlint. If you click on it, you’ll get a full log with rpmlint output.
If you wish to whitelist some errors which are not relevant for your package or are clearly a mistake (like spelling issues, etc), it is now possible. The steps how to do this are described at:
This has been often requested, so hopefully this will help you have the automated tests results all in green, instead of being bothered by invalid errors. If something doesn’t work, and it seems to be our bug in how we execute rpmlint (instead of a bug in rpmlint itself), please file a bug in task-rpmlint or contact us (qa-devel mailing list, #fedora-qa IRC channel on Freenode).
If you are a Fedora packager, you might be interested to know that in Taskotron we replaced the depcheck task with rpmdeplint task. So if there are any dependency issues with the new update you submit to Bodhi, you’ll see that as dist.rpmdeplint failure (in the Automated Tests tab). The failure logs should look very similar to the depcheck ones (basically, the logs contain the errors dnf would spit out if it tried to install that package), so there should be no transitioning effort needed.
If you listen for depcheck results somehow, i.e. in FMN, make sure to update your rules to listen for dist.rpmdeplint instead. We have updated the default filters in FMN, so if you haven’t changed them, you should receive notifications for failures in rpmdeplint (and also upgradepath and abicheck) for submitted updates owned by you.
The reason for this switch is that we wanted to get rid of custom dependency checking (done directly on top of libsolv), and use an existing tool for that instead. That saves us time, we don’t need to study all the pitfalls of dependency resolution, and we benefit from someone else maintaining and developing the tool (that doesn’t mean we won’t send patches if needed). rpmdeplint offered exactly what we were looking for.
We will decommission depcheck task from Taskotron execution in the next few days, if there are no issues. Rpmdeplint results are already being published for all proposed updates.
Hello, I’d like to introduce a new sub-planet of Fedora Planet to you, located at http://fedoraplanet.org/quality/ (you don’t need to remember the URL, there’s a sub-planet picker in the top right corner of Fedora Planet pages that allows you to switch between sub-planets).
Fedora Quality Planet will contain news and useful information about QA tools and processes present in Fedora, updates on our quality automation efforts, guides for package maintainers (and other teams) how to interact with our tools and checks or understand the reported failures, announcements about critical issues in Fedora releases, and more.
Our goal is to have a single place for you to visit (or subscribe to) and get a good overview of what’s happening in the Fedora Quality space. Of course all Fedora Quality posts should also show up in the main Fedora Planet feed, so if you’re already subscribed to that, you shouldn’t miss our posts either.
If you want to join our effort and publish some interesting quality-related posts into Fedora Quality Planet, you’re more then welcome! Please see the instructions how to syndicate your blog. If you have any questions or need help, ask in the test mailing list or ping kparal or adamw on #fedora-qa freenode IRC channel. Thanks!
I haven’t seen any announcement, but I noticed Fedora repositories now contain edk2-ovmf package. That is the package that is necessary to emulate UEFI in QEMU/KVM virtual machines. It seems all licensing issues having been finally resolved and now you can easily run UEFI systems in your virtual machines!
I have updated Using_UEFI_with_QEMU wiki page accordingly.
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.
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.
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.