Tag Archives: Fedora Gooey Karma

Gooey Karma – in Fedora!

I am really glad that I can announce that Fedora Gooey Karma is finally in Fedora’s stable repository. I would like to say thank you to Miroslav Suchý who helps me with review process (bug BZ#1020839) and also sponsored me in packager group.

This is great success for me and I hope that it will be next step to bring Fedora testing closer to people.

If you would like to install Fedora Gooey Karma it is as easy as any other package:

# yum install fedora-gooey-karma

Gooey Karma – Final thoughts, known bugs, future of FGK

On 16th of september was soft “pencils down” deadline for GSoC projects. What I did is fully working application for submitting karma to Bodhi. You can find out more on wiki page which contains screenshots, list of classes and methods, scheme of threads and some words about Gooey Karma.

Known bugs

It has bugs of course. Kamil Paral found most of them and you can see them in issues. Issue #13 is the worst one but I am going to fix it soon and hopefully the performance of reloading packages will be better too.

What to do next

I’ve decided to continue working on this tool. You can take a look into branch qml of FGK’s repository (directory src/ui) to view on what I will work next. I would like to rewrite the GUI to QML because of Qt limitations I was not able to make user-friendly-enough interface. I hope that this change will bring testing and FGK closer to regular Fedora users.

Do you want to try Fedora Gooey Karma? See this!

Gooey Karma – fixed QSignal issues and more

As I wrote in the last blog post there were some issues with QSignal (or QThreads). I’ve rewritted the code to use self-designed signal-slot system as it’s shown here. This fixed all crashes and Fedora Gooey Karma is stable now.

I would like to thank Kamil Paral for his issues which he reported. I’ve made several bug fixes and usage enhancements according to his suggestions.

If you have any other ideas how to make Fedora Gooey Karma better, please feel free to add an issue.

Do you want to try Fedora Gooey Karma? See this!

Gooey Karma – news and problems

There are few new changes from the last post. As I mentioned how will What to test section looks like – it is fully working now. Give it a try!

Layout news

One of the most satisfying thing for me is progress bar. It’s great that you can see how many per cent of packages is loaded.


Karma user filter support ‘Karma not submitted by user’ and ‘Karma submitted by user’ now. So you can look for both types of updates.



I am using QThread, QSignal and Python Queue for threads and transferring data between spawned threads and main thread. Application is randomly crashing on random places and I am not sure where is the problem. I tried to get the shortest backtrace and filled a bug. I’ve discussed it with Python maintainer in Red Hat and he said that’s probably bug in QT so I hope it is true and will be fixed soon. Now I am trying to workaround it or to find a problem in my code.

If you have some suggestions please let me know.

Do you want to try Fedora Gooey Karma? See this!

Gooey Karma – what to test section, new layout

A lot of users do not know what to test and they see only a long list of available Bodhi updates but can’t decide where to start.

What to test section

I’ve discussed this problem with my mentor and Fedora Gooey Karma has What to test section now. This section will be start point for testing the new updates. It contains several tools which I will describe in their own section.

Updates with negative karma

This tool provides a list of updates which has one negative comment at least. These are a very good candidates to test.


Currently running applications

This tool will monitor running processes and match them with available Bodhi updates. For example if you are running Firefox and there is Firefox in updates it will suggest you to test it because you are using it. There is a high chance that you know how to test it when you are using it right now.

Favorite and ignored packages

You can add your favorite packages and Fedora Gooey Karma will remember it and if this package would have available update to test it will appear in this list. There is also a list of ignored packages. If you add some package to this list it will no longer appear in package list on the left with Bodhi updates.


New layout

As Fedora Gooey Karma is getting new features it’s very hard to make it simple and user-friendly as well. Tools mentioned above are separated to new tab now. Currently selected update is next to it.

Opened update contains other 3 tabs with main info, comments and tools/settings. The last tab contains buttons to open bodhi update in browser or to download source RPM.

update1 update2 update3

First time with Fedora Gooey Karma

Fedora Gooey Karma now has its own repository! It was developed by examon (Tomas Meszaros) who wrote some basic functionality before. I’ve forked his repository and created a new one which will be the main for Google Summer of Code.

Problem with threads

Tomas did a lot of great work but the code needed some tweaks. The main problem I’ve hit was with threads in Python. BodhiClient query started from thread got stuck in deadlock. It’s important to have internet queries in different thread than main GUI to don’t get it freeze for user.

So I filled a bug 972429 against fedora-python (it contains BodhiClient class) because I thought it’s problem with that. After IRC discussion with Toshio Kuratomi we figured out that problem is in implementation of python (or QT) threads. Thread cannot be spawned from imported library as it’s mentioned on the very bottom of official docs page.

Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module.

This problem was pretty serious because Tomas’s code has pretty much everything imported from one main file. I had to rewrite it to some “less abstract” code. I’ve split classes to separated files. Now we have two main “workers”. :) One is for packages which get info mainly from RPM database or YUM. Second one is communicating with Bodhi servers. Application spawns 15 threads of Bodhi workers now and I hope it will be good enough to have relevant results from servers in quite a short time.

You can see these changes in this and this commit.

What to do next

Now I’m going to edit Makefile to have it properly “installable” on system because it’s runnable from src/fedora-gooey-karma which can be a little confusing for random strangers now. :)

Fedora Gooey Karma as Google Summer of Code project

After recommendation from my classmate I’ve decided to join Google Summer of Code for year 2013. Firstly I had to decide which organization and project I would like to contribute. Fedora was the first organization which came to my mind so I’ve started to read about projects on wiki idea page.

As a tester I’ve scrolled down to the section “Applications for Testers” and Fedora Gooey Karma was the best for me. I really like the idea of adding karma to new patches and how people can contribute/decide what will be in updates. I know something about project Fedora Easy Karma which is a CLI tool for adding karma via Bodhi. I am a big fan of CLI tools but it’s not enough user-friendly for this kind of work. So I’ve decided to try it.

After discussions with mentors I’ve written proposal and “won” this project for this year of GSOC.

GUI tool should bring more people to be part of testing part and I am glad that I will be part of it.

Next steps

I am waiting to get writing access to correct repository and studying functionality of Fedora Easy Karma and Bodhi library.

I would like to prepare a few functions to communicate with Fedora servers and get some basic information about updates or comments which I will surely need in Fedora Gooey Karma.