KVM disk performance: raw vs qcow2 format

Some time ago I compared disk drivers performance in KVM. Today I compared different storage formats – raw and qcow2. Let’s have a look:

Test procedure: Create an empty 10 GB image, attach to VM using VirtIO driver, boot F20 Alpha Live x86_64, measure the time of installation. Repeat installation once again, this time reusing the existing image (instead of creating a new one). Do this for both formats.

Test results:

raw 1st pass          2:36
raw 2nd pass          2:38
qcow2 1st pass        2:36
qcow2 2nd pass        2:44

As you can see, the results are very much the same. It seems it doesn’t matter much which format you use.

But, qcow2 format has some nice additional features, like copy-on-write cloning. If I need to test something very quickly in my existing VM and then revert the changes back, this is the easiest way:

$ cd /var/lib/libvirt/images
$ mv f19.qcow2 f19.qcow2_orig
$ qemu-img create -f qcow2 -b f19.qcow2_orig f19.qcow2
Formatting 'f19.qcow2', fmt=qcow2 size=10737418240 backing_file='f19.qcow2_orig' encryption=off cluster_size=65536 lazy_refcounts=off
$ # Run the VM now and do your tasks
$ mv f19.qcow2_orig f19.qcow2

Enjoy.

Flattr this

Experiment with bleeding-edge GNOME using GnomeOSTree

I have just discovered GnomeOSTree (I’ve heard about it before, but never tried it). It allows you to run an absolutely fresh version of GNOME (checked out from git the very day) in a virtual machine. This is perfect for

  • experimenting with new features
  • checking whether a bug still exists in the development version
  • checking whether a bug fix is correct, without waiting for a distribution package update

I’ve just played with it for 10 minutes, so I might be missing a lot of things, but this seems to be a very useful tool for anyone testing and reporting GNOME bugs. It’s extremely easy to set up, you just download a VM disk image and import it into virt-manager. Later you can update it from inside the system. Try it!

ostree

Flattr this

The heroes of Fedora updates testing in Q2 2013

1360095720_PrizeAnother quarter is gone, let’s see how much testing of proposed updates in Fedora we have done. The purpose of this testing is to make sure that broken updates don’t enter our stable (or soon-to-be-stable) Fedora releases. The test feedback is managed inside Bodhi application and here are the statistics for the recent quarter:

Test period: Q2 2013 (2013-04-01 – 2013-06-30)
Testers: 669
Comments1: 3891

Name Updates commented
Adam Williamson (adamwill) 231
Reindl Harald (hreindl) 224
Igor Gnatenko (ignatenkobrain) 224
T.C. Hollingsworth (patches) 174
Kevin Fenzi (kevin) 169
Robert C. Lightfoot (boblfoot) 125
misc 124
Kalev Lember (kalev) 111
Alexander Kurtakov (akurtakov) 107
Piotr Drąg (raven) 106
nonamedotc 102
bitlord 99
Ankur Sinha (ankursinha) 72
Kamil Páral (kparal) 69
quickbooks 65
Daniel Dimitrov (dandim) 63
Matthias Runge (mrunge) 46
Michael Schwendt (mschwendt) 39
mharmsen 32
keramidas 30
Peter Robinson (pbrobinson) 26
Rex Dieter (rdieter) 26
bojan 26
Wolfgang Ulbrich (raveit65) 25
Dan Mashal (vicodan) 23
Jack Magne (jmagne) 18
Nick Bebout (nb) 18
gwei3 17
Orion Poplawski (orion) 16
bradw 16
Adam Domurad (adomurad) 16
Matthias Clasen (mclasen) 16
nucleo 16
Endi Sukma Dewata (edewata) 15
Michael Catanzaro (catanzaro) 14
Arthur Scott Poore (spoore) 13
Sérgio Monteiro Basto (sergiomb) 13
Joel Burleson-Davis (sysengbd) 12
Tao Wu (wutao85) 12
Tom Callaway (spot) 12
Adam Jackson (ajax) 12
Abhishek Koneru (kaskahn) 12
Jens Petersen (petersen) 11
Joachim Backes (backes) 11
Ed Greshko (egreshko) 11
Heiko Adams (heikoada) 11
Dan Horák (sharkcz) 11
Freddy Willemsen (freddyw) 11
Christian Lockley (clockley1) 10
Samuel Sieb (ssieb) 10
robatino 10
amessina 10
Mamoru Tasaka (mtasaka) 10
Fabian Deutsch (fabiand) 10
Vojtech Bocek (tassadar) 9
Hans Müller (cairo) 9
Fabio Valentini (fafatheone) 9
Pete Walter (pwalter) 8
mooninite 8
leigh123linux 8
Zbigniew Jędrzejewski-Szmek (zbyszek) 7
Oron Peled (oron) 7
Peter Borsa (asrob) 7
Christopher Meng (cicku) 7
Tim Flink (tflink) 7
rcritten 7
Omair Majid (omajid) 7
Dean Hunter (deanhunter) 7
jerboaa 7
Mike FABIAN (mfabian) 7
Cristian Ciupitu (ciupicri) 7
Dennis Gilmore (ausil) 6
Martin Krizek (mkrizek) 6
Mikolaj Izdebski (mizdebsk) 6
Artyom (artkun) 6
Bruno Wolff III (bruno) 6
Simone Caronni (slaanesh) 6
Pavel Tisnovsky (ptisnovs) 6
Patrick Uiterwijk (puiterwijk) 6
Remi Collet (remi) 6
John Reiser (jreiser) 6
David Juran (djuran) 6
D. Charles Pyle (dcharlespyle) 6
pnemade 6
Josef Stribny (jstribny) 5
nixfas 5
Morten Stevens (mstevens) 5
Lijun Li (lijli) 5
Andrew Azores (aazores) 5
Kevin Kofler (kkofler) 5
avij 5
Axilleas Pipinellis (axilleas) 5
Ville Skyttä (scop) 5
Luke Macken (lmacken) 5
Chris Murphy (chrismurphy) 5
Johan Hedin (jhn) 5
Chad Feller (cfeller) 5
Nils Philippsen (nphilipp) 5
Germano Massullo (germano) 5
Elad Alfassa (elad) 5
David A. Marlin (dmarlin) 5
Martin Kosek (mkosek) 5
Dominic Hopf (dmaphy) 5
Karsten Hopp (karsten) 5
Šimon Lukašík (isimluk) 5
Tim Waugh (twaugh) 5
Vít Ondruch (vondruch) 5
tomspur 5
Samuel Greenfeld (greenfeld) 5
…and also 560 other reporters who created less than 5 reports each, but 848 reports combined!

1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

When compared to Q1 2013, the number of reporters remained steady, but the number of reports increased almost twofold. That is amazing, I suspect it’s directly related to the Fedora 19 stabilization cycle and release.

The top-performers have almost an even score, which is great to see. They are Adam Williamson (adamwill), Reindl Harald (hreindl) and Igor Gnatenko (ignatenkobrain). Thank you guys for your outstanding and steadfast performance!

It’s also interesting to see that in the top 15 list there are only 4 Red Hatters (Adam, Kevin, Alexander and me), all the rest are community participants. I love that fact very much. Testing might not always be fully engaging, but still, paid employees are the minority here. What a strong community.

If you see yourself in the table, or if you are somewhere below the threshold, thank you. Your effort makes Fedora stable and reliable.

If you haven’t participated yet, maybe it’s time to give it a try? You can start today! Just read QA:Updates_Testing and ask any questions in #fedora-qa on IRC or test list. We would love to see even more people involved.

Thanks everyone.


When reading the statistics, please take it with a grain of salt. Not all numbers are directly comparable. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.

The heroes of Fedora 19 Final testing

1360095720_PrizeFedora 19 the Schrödinger’s Cat is out of the box, and alive! I have again gathered some interesting statistics about QA contributions, this time during the Final phase (between Beta and Final release).

Fedora 19 Final – wiki matrices

This is the list of people who filled in our release validation wiki matrices (Install, Desktop and Base), which are posted for every test compose (and release candidate) that we create. The purpose is to see which areas have been thoroughly tested and which were not.

Test period: Fedora 19 Beta – Fedora 19 Final
Testers: 29
Reports: 1035
Unique referenced bugs: 58

Name Reports submitted Referenced bugs1
robatino 259 929177 946964 958426 958427 972025 972046 974050 974052 975227 975230 975324 975325 976280 976281 977669 977671 977715 977732 978114 978124 978125 979171 979172 (23)
nonamedotc 127 972225 977879 (2)
adamwill 103 858270 892178 975800 978008 (4)
kparal 103 973068 974032 974038 977715 977816 977962 (6)
Wutao85 55
lbrabec 49 855824 858270 977962 978298 (4)
jpospisi 48 964586 975483 (2)
eischmann 39
lnie 24
pkotvan 23 969684 975813 (2)
jskladan 21
tflink 21 975495 (1)
mkrizek 21 977962 (1)
jsedlak 19 973747 975375 978346 (3)
pschindl 18
lnovy 16 743281 858270 (2)
mmarhefk 16 892178 959796 975521 (3)
Martix 15 976417 (1)
boblfoot 12 971191 (1)
jreiser 12 976582 (1)
kevin 10
satellit 10
werkman 5 971109 971255 976034 (3)
todoleza 3 970988 (1)
konradr 2 977974 977987 978036 (3)
mattdm 1
jreznik 1 705086 (1)
mooninite 1
dgilmore 1

1 This is a list of bug reports linked to the wiki results. They don’t have to be reported by that concrete person.

Who would have thought… Andre Robatino (robatino) is at the top again. It’s also very nice to see how many bugs he referenced during his testing. The more referenced bugs the more publicity, the more likeliness that someone reproduces them, the more likeliness someone fixes them. Thanks, Andre!

The community participation list continues with nonamedotc, who provided an amazing number of test case results as well. Then there is a long list of Red Hatters, the highest score split between Adam Williamson (adamwill) and Kamil Páral (kparal) (a.k.a. me). Since I referenced more bugs, I consider myself a winner 😛 “I only believe in statistics that I doctored myself.” 🙂

The community participation continues with Bob Lightfoot (boblfoot), who had been greatly active during Beta, John Reiser (jreiser), Thomas Gilliard (satellit) and others. Thank you, everyone.

Fedora 19 Final – Bugzilla

This is a trimmed list of people who reported bugs into Bugzilla against Fedora 19 in the specified time period. When compared to Fedora 19 Beta, the numbers went up again, especially the number of reporters. That’s really great.

Test period: Fedora 19 Beta – Fedora 19 Final (2013-05-29 – 2013-06-28)
Reporters: 614
New reports: 1486

Name Reports submitted1 Excess reports2 Accepted blockers3
IBM Bug Proxy 31 2 (6%) 0
Mark Salter 31 2 (6%) 0
Adam Williamson 27 1 (3%) 2
quickbooks.office at gmail.com 27 1 (3%) 1
Mikhail 26 1 (3%) 0
David Woodhouse 23 0 (0%) 0
Kamil Páral 22 2 (9%) 4
Andre Robatino 21 18 (85%) 1
Zbigniew Jędrzejewski-Szmek 17 0 (0%) 0
Dan Mashal 16 4 (25%) 0
Karel Volný 16 0 (0%) 0
Vojtěch Boček 13 0 (0%) 2
Emmanuel Pacaud 13 0 (0%) 0
Marian 12 3 (25%) 0
Jan Sedlák 11 0 (0%) 0
Lukas Brabec 11 1 (9%) 0
Martin Holec 11 2 (18%) 0
Tim Waugh 11 0 (0%) 0
A.J. Werkman 10 0 (0%) 0
Florian Weimer 10 0 (0%) 0
Heiko Adams 10 0 (0%) 0
Joachim Backes 10 3 (30%) 0
Chris Murphy 9 0 (0%) 1
Bojan Smojver 9 0 (0%) 0
Diogo Campos 9 0 (0%) 0
Jonas Thiem 9 0 (0%) 0
David Jaša 8 1 (12%) 0
Dean Hunter 8 1 (12%) 0
Endi Sukma Dewata 8 2 (25%) 0
James 8 2 (25%) 0
Jeff Bastian 7 1 (14%) 1
Jiří Martínek 7 1 (14%) 0
Marcus Moeller 7 3 (42%) 0
Matthew Miller 7 0 (0%) 0
Simon Lewis 7 1 (14%) 0
TKS 7 1 (14%) 0
Mark Hamzy 6 0 (0%) 1
Nix\ 6 2 (33%) 1
arnav 6 2 (33%) 0
Kalev Lember 6 1 (16%) 0
Krzysztof Daniel 6 0 (0%) 0
Rolle 6 1 (16%) 0
Russ Anderson 6 1 (16%) 0
Siddhesh Poyarekar 6 0 (0%) 0
James Heather 5 0 (0%) 1
Jiri Eischmann 5 1 (20%) 1
Michael Scherer 5 0 (0%) 1
Alexey Derlaft 5 2 (40%) 0
Andrea Oliveri 5 1 (20%) 0
Björn Esser 5 0 (0%) 0
D. Charles Pyle 5 0 (0%) 0
Dennis Gilmore 5 0 (0%) 0
Edgar Hoch 5 0 (0%) 0
Flóki Pálsson 5 1 (20%) 0
Francisco de la Peña 5 1 (20%) 0
Joshua Holm 5 0 (0%) 0
Konrad Rzeszutek Wilk 5 0 (0%) 0
Lukas -krtek.net- Novy 5 2 (40%) 0
mark 5 0 (0%) 0
Matthias Clasen 5 0 (0%) 0
nonamedotc at gmail.com 5 2 (40%) 0
Parag 5 2 (40%) 0
Paul Whalen 5 0 (0%) 0
Reartes Guillermo 5 0 (0%) 0
Vít Ondruch 5 0 (0%) 0
Álvaro Castillo 5 0 (0%) 0
Štefan Gurský 5 0 (0%) 0
…and also 547 other reporters who created less than 5 reports each, but 834 reports combined!

1 The total number of new reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data.
2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable.
3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.

The top reporters are nicely and evenly distributed, there are no extreme performers as in the wiki statistics. The top position share IBM Bug Proxy and Mark Salter. Mark reported a number of build failures for ARM architecture. I assume IBM Bug Proxy is probably a shared account among IBM employees who care about Fedora development – they reported a number of anaconda, kernel and boot issues. It’s always nice to see other companies involved in raising the Fedora quality – welcome, IBM 🙂

When it comes to general bug reporting, the top Red Hatter is Adam Williamson. As for the community, quickbooks.office reported the same number of bugs, most of them being SELinux error duplicates. Mikhail closely follows with a much more interesting mix of bug reports, which also applies for David Woodhouse. The community list follows with Andre Robatino (mostly fake bug reports for test purposes), Zbigniew Jędrzejewski-Szmek, Dan Mashal and others.

It’s great to see so many bug reports and so even distribution of the top reporters. Thanks, all of you.

Fedora 19 Beta – updates testing

This is a trimmed list of people who provided feedback in Bodhi for all updates proposed into Fedora 19 in the specified time period. The purpose is to make sure that broken updates do not enter the stable repository and the release continuously stabilizes. The number of testers increased considerably again as compared to Beta.

Test period: Fedora 19 Beta – Fedora 19 Final (2013-05-29 – 2013-06-28)
Testers: 240
Comments1: 1107

Name Updates commented
Igor Gnatenko (ignatenkobrain) 155
Adam Williamson (adamwill) 76
nonamedotc 71
Kalev Lember (kalev) 57
Alexander Kurtakov (akurtakov) 47
bitlord 45
T.C. Hollingsworth (patches) 41
quickbooks 35
Piotr Drąg (raven) 29
Kevin Fenzi (kevin) 28
Ankur Sinha (ankursinha) 20
keramidas 20
misc 20
Michael Schwendt (mschwendt) 16
Peter Robinson (pbrobinson) 15
Wolfgang Ulbrich (raveit65) 13
Dan Mashal (vicodan) 13
Matthias Clasen (mclasen) 12
Matthias Runge (mrunge) 11
bojan 10
Kamil Páral (kparal) 9
leigh123linux 8
D. Charles Pyle (dcharlespyle) 6
Pete Walter (pwalter) 6
Joachim Backes (backes) 6
mharmsen 6
Rex Dieter (rdieter) 5
Dennis Gilmore (ausil) 5
Ed Greshko (egreshko) 5
Dominic Hopf (dmaphy) 5
Endi Sukma Dewata (edewata) 5
Abhishek Koneru (kaskahn) 5
Kai Engert (kengert) 4
Jiri Eischmann (eischmann) 4
pnemade 4
Martin Kho (mkho) 4
Vojtech Bocek (tassadar) 4
Reindl Harald (hreindl) 4
Heiko Adams (heikoada) 4
Ian Malone (imalone) 3
Lukas Brabec (lbrabec) 3
Anton Arapov (aarapov) 3
Dan Horák (sharkcz) 3
Ray Strode (rstrode) 3
Hans Müller (cairo) 3
Greg Schlau (gregschlau) 3
Sérgio Monteiro Basto (sergiomb) 3
Nathan Kinder (nkinder) 3
gil 3
Martin Kosek (mkosek) 3
Artyom (artkun) 3
Roland Grunberg (rgrunber) 3
…and also 188 other reporters who created less than 3 reports each, but 235 reports combined!

1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

A new star has emerged, Igor Gnatenko (ignatenkobrain) completely dominated here. Great job, Igor! The top performing Red Hatter was, yet again, Adam Williamson (adamwill).

The top community list, apart from Igor, also contains nonamedotc, Kalev Lember (kalev), bitlord, T.C. Hollingsworth (patches), quickbooks, Piotr Drąg (raven), and others. It’s great to see so many people involved, because testing proposed updates and providing karma is one of the easiest way to contribute, yet extremely important at the same time. Thanks to anyone who contributed!

Summary

For most parts, the number of reports stays similar to Beta, but the number of people involved rose considerably. Beta release seems to be very attractive to the Fedora community and rightly so, it’s the last step before everything is pronounced stable. We’re glad to see so many people involved in release testing and we hope that we will see you again in Fedora 20 cycle!

In the meantime you can help as well – for example testing the proposed updates for stable Fedora releases is as useful, maybe even more important, than for releases in development. You can also play with Rawhide and help us find the bugs well in advance. There is a lot of possibilities – if it sounds interesting to you, be sure to have a look at QA/Join, follow the announcements and talk to us in #fedora-qa on IRC and test list. Your involvement will help not only Fedora and its users, but the whole Linux ecosystem. Thanks!


When reading the statistics, please take it with a grain of salt. The numbers are not directly comparable. People might see some reports as more valuable than others. Some people tested a lot of components, but haven’t found many problems (but that also helps). Some people used their skills in other areas than those mentioned. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.

The heroes of Fedora 19 Beta testing

1360095720_PrizeFedora 19 Beta was released last week. As usual, here are some interesting statistics from different areas of our testing efforts. No matter how large your contribution was, if you’ve helped us, thank you.

Fedora 19 Beta – wiki matrices

This is the list of people who filled in our release validation wiki matrices (Install, Desktop and Base), which are posted for every test compose (and release candidate) that we create. The purpose is to see which areas have been thoroughly tested and which were not.

Test period: Fedora 19 Alpha – Fedora 19 Beta
Testers: 27
Reports: 837
Unique referenced bugs: 63

Name Reports submitted Referenced bugs1
boblfoot 222 950487 951951 959605 959719 959793 959796 960837 962248 962569 963503 964586 965213 (12)
robatino 195 929177 946964 958424 958426 958427 958430 958436 959610 963547 964069 (10)
tassadar 72 920549 962039 962092 962701 965101 965663 965940 965974 966086 966095 966894 (11)
nonamedotc 71 951951 958436 958512 959796 (4)
adamwill 41 858270 950022 964352 966424 966598 (5)
Wutao85 40 963503 (1)
kparal 35 810112 892178 922885 950022 951951 (5)
satellit 34 922958 960045 96045 960791 (4)
lnie 23
pkotvan 13
fholec 13 929958 964587 965516 965539 965544 965633 965731 (7)
kevin 12 963238 964356 (2)
jskladan 11
mkrizek 11 948099 (1)
lbrabec 9 964147 964176 (2)
vicodan 9
prcek 7 967748 (1)
ausil 4 959610 (1)
pschindl 3 958697 966586 (2)
tflink 2 962831 (1)
mmarhefk 2
jsedlak 2
tasssadar 2
Lalatendu 1 966025 (1)
jthorne 1
adamw 1 958512 (1)
jpospisi 1

1 This is a list of bug reports linked to the wiki results. They don’t have to be reported by that concrete person.

The two titans waged a battle, and in the end, Bob Lightfoot (boblfoot) prevailed, for the first time! 🙂 Congratulations, Bob. Andre Robatino (robatino) very closely followed. After them, there is Vojtěch Boček (tassadar), a high school student who spent two weeks on internship in Red Hat, and then nonamedotc with nearly exactly the same score. The number one Red Hatter became Adam Williamson (adamwill), closely followed by a few other Red Hat employees and Thomas Gilliard (satellit). Great job, guys, thank you! Of course, everyone else’s help is fully appreciated as well.

Fedora 19 Beta – Bugzilla

This is a trimmed list of people who reported bugs into Bugzilla against Fedora 19 in the specified time period. Compared to Fedora 19 Alpha statistics, the already high numbers went even higher – the number of reporters went up by 50%. Nice to see.

Test period: Fedora 19 Alpha – Fedora 19 Beta (2013-04-24 – 2013-05-28)
Reporters: 463
New reports: 1538

Name Reports submitted1 Excess reports2 Accepted blockers3
Adam Williamson 60 4 (6%) 2
Dhiru Kholia 49 1 (2%) 0
Mikhail 32 6 (18%) 0
Reartes Guillermo 29 6 (20%) 1
Stef Walter 29 1 (3%) 0
Chris Murphy 27 1 (3%) 5
vinesh teotia 27 0 (0%) 0
Andre Robatino 20 11 (55%) 4
Robert Lightfoot 18 2 (11%) 1
Lennart Poettering 18 0 (0%) 0
Ankur Sinha (FranciscoD) 16 1 (6%) 0
Patrik Kis 16 1 (6%) 0
Vojtěch Boček 16 1 (6%) 0
Dean Hunter 15 1 (6%) 0
IBM Bug Proxy 15 1 (6%) 0
Zbigniew Jędrzejewski-Szmek 15 0 (0%) 0
Grosswiler Roger 14 0 (0%) 0
Igor Gnatenko 14 4 (28%) 0
Luis Bazan 14 0 (0%) 0
Mikolaj Izdebski 13 0 (0%) 0
D. Charles Pyle 12 3 (25%) 0
David Spurek 12 3 (25%) 0
Hans de Goede 12 0 (0%) 0
Jeff Bastian 12 1 (8%) 0
Mark Salter 12 0 (0%) 0
Martin Banas 12 1 (8%) 0
Bill Nottingham 10 1 (10%) 0
Flóki Pálsson 10 2 (20%) 0
Jan Stodola 10 1 (10%) 0
John Reiser 10 0 (0%) 0
nucleo 10 1 (10%) 0
quickbooks.office at gmail.com 10 1 (10%) 0
Lawrenc Graves 9 0 (0%) 0
Matthew Miller 9 0 (0%) 0
Michael Scherer 9 0 (0%) 0
Mike FABIAN 9 1 (11%) 0
Need Real Name 9 4 (44%) 0
Nix\ 9 0 (0%) 0
satellit at bendbroadband.com 9 0 (0%) 0
Stephen Gallagher 9 1 (11%) 0
Dan Horák 8 0 (0%) 1
Alex Murray 8 0 (0%) 0
Amit Shah 8 0 (0%) 0
Jens Petersen 8 1 (12%) 0
Joachim Backes 8 2 (25%) 0
Marian Ganisin 8 1 (12%) 0
Mark Hamzy 8 2 (25%) 0
Orion Poplawski 8 1 (12%) 0
Peter Robinson 8 0 (0%) 0
Petr Schindler 8 1 (12%) 0
Simon Lewis 8 1 (12%) 0
Tomas Dolezal 8 0 (0%) 0
A.J. Werkman 7 0 (0%) 0
David Jaša 7 0 (0%) 0
Ed Greshko 7 0 (0%) 0
Richard W.M. Jones 7 0 (0%) 0
Evan Nemerson 6 0 (0%) 0
Jay Finger 6 0 (0%) 0
Jiri Koten 6 0 (0%) 0
Lukas -krtek.net- Novy 6 0 (0%) 0
Parag 6 1 (16%) 0
R P Herrold 6 4 (66%) 0
Vít Ondruch 6 1 (16%) 0
Pavel Holica 5 1 (20%) 1
a554335752 5 0 (0%) 0
Ales Ledvinka 5 0 (0%) 0
Andy Lawrence 5 0 (0%) 0
Cole Robinson 5 0 (0%) 0
Dan Mashal 5 0 (0%) 0
David Woodhouse 5 0 (0%) 0
Filip Holec 5 0 (0%) 0
Hein Kerstgens 5 0 (0%) 0
Joel 5 0 (0%) 0
Kalev Lember 5 0 (0%) 0
kuchiman 5 0 (0%) 0
Matthias Runge 5 0 (0%) 0
Michal Domonkos 5 0 (0%) 0
Patryk Zawadzki 5 0 (0%) 0
Philipp Dreimann 5 0 (0%) 0
Tim Flink 5 1 (20%) 0
Tim Waugh 5 1 (20%) 0
wangjiezhe at gmail.com 5 0 (0%) 0
William Brown 5 3 (60%) 0
…and also 380 other reporters who created less than 5 reports each, but 611 reports combined!

1 The total number of new reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data.
2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable.
3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.

The gold crown in the number of bug reports is won by our famous “community monkey”, Red Hatter Adam Williamson. Dhiru Kholia continues to report packaging issues, as before. Mikhail and Reartes Guillermo lead the community efforts in standard bug reporting, together with Chris Murphy, vinesh teotia, Andre Robatino, Robert Lightfoot and others. Chris and Andre were very successful in proposing Beta blocker bugs.

It’s always nice to see how many people participate in bug reporting, the numbers are breathtaking. I hope it doesn’t mean that our quality is really low 🙂 I believe this indicates the opposite – we have an amazing number of people trying to ensure the quality is as high as possible. Thank you.

Fedora 19 Beta – updates testing

This is a trimmed list of people who provided feedback in Bodhi for all updates proposed into Fedora 19 in the specified time period. The purpose is to make sure that broken updates do not enter the stable repository and the release continuously stabilizes.

Test period: Fedora 19 Alpha – Fedora 19 Beta (2013-04-24 – 2013-05-28)
Testers: 164
Comments1: 1054

Name Updates commented
Robert C. Lightfoot (boblfoot) 117
Adam Williamson (adamwill) 102
misc 70
Piotr Drąg (raven) 56
Igor Gnatenko (ignatenkobrain) 55
Kevin Fenzi (kevin) 52
bitlord 47
T.C. Hollingsworth (patches) 45
Ankur Sinha (ankursinha) 42
Kalev Lember (kalev) 36
Alexander Kurtakov (akurtakov) 30
nonamedotc 28
Matthias Runge (mrunge) 25
Michael Schwendt (mschwendt) 18
gwei3 11
Jack Magne (jmagne) 10
Vasileios Keramidas (keramidas) 9
nucleo 9
Rex Dieter (rdieter) 8
mharmsen 8
Dan Mashal (vicodan) 8
Fabio Valentini (fafatheone) 8
Orion Poplawski (orion) 7
Arthur Scott Poore (spoore) 7
Tom Callaway (spot) 7
Heiko Adams (heikoada) 7
Wolfgang Ulbrich (raveit65) 6
Zbigniew Jędrzejewski-Szmek (zbyszek) 6
Axilleas Pipinellis (axilleas) 5
Christopher Meng (cicku) 5
Adam Jackson (ajax) 5
Tim Flink (tflink) 5
Joel Burleson-Davis (sysengbd) 4
Vojtech Bocek (tassadar) 4
Tao Wu (wutao85) 4
Mamoru Tasaka (mtasaka) 4
robatino 4
Endi Sukma Dewata (edewata) 4
Elad Alfassa (elad) 3
David A. Marlin (dmarlin) 3
Mike FABIAN (mfabian) 3
Stef Walter (stefw) 3
Chris Murphy (chrismurphy) 3
David King (amigadave) 3
Daniel J Walsh (dwalsh) 3
halfie 3
John Reiser (jreiser) 3
Patrik Kis (pkis) 3
Petr Schindler (pschindl) 3
Martin Krizek (mkrizek) 3
…and also 114 other reporters who created less than 3 reports each, but 140 reports combined!

1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is not taken into account.

When compared to F19 Alpha statistics, the number of reporters increased by half and the number of comments increased more than 3 times. Nice. This is one of the easiest way how to contribute to Fedora quality and I’m very glad that the numbers soared so much. Our hero is, as usual, Robert C. Lightfoot (boblfoot)! The other high-profile community contributors include misc, Piotr Drąg (raven), Igor Gnatenko (ignatenkobrain), bitlordT.C. Hollingsworth (patches), Ankur Sinha (ankursinha) and others. The most active Red Hatter was, once again, Adam Williamson. Great job, everyone.

Summary

I’m very glad to see a visible increase in test activities since F19 Alpha. Surely, the officially released milestone composes (i.e. Alpha, Beta) help to attract more testers than just the regular contributors base. It will be interesting to see how the picture changes between Fedora 19 Beta and Final.

If you are interested in raising the Fedora quality up, help us out. Read QA/Join, follow the announcements and talk to us in #fedora-qa on IRC and test list. We will love to see you!


When reading the statistics, please take it with a grain of salt. The numbers are not directly comparable. People might see some reports as more valuable than others. Some people tested a lot of components, but haven’t found many problems (but that also helps). Some people used their skills in other areas than those mentioned. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.

The heroes of Fedora updates testing in Q1 2013

1360095720_PrizeRecently I’ve published a list of contributors who helped to test Fedora 19 Alpha. But Quality Assurance doesn’t involve just in-development releases. We need to ensure that stable releases also work well. One of the major ways to achieve that is to make sure that broken package updates don’t enter stable updates repository. We use Bodhi system for that. I have gathered the data about Bodhi feedback contributors regardless of Fedora release involved and present it here.

Who are the heroes who watch the Fedora borders and guard us against broken software updates?

Test period: Q1 2013 (2013-01-01 – 2013-03-31)
Testers: 657
Comments1: 2203

Name Updates commented
hreindl 278
patches 94
kparal 92
mrunge 53
adamwill 48
akshayvyas29 41
mooninite 33
kevin 32
ankursinha 26
rdieter 25
keramidas 25
bojan 23
nucleo 23
boblfoot 20
pwalter 18
cfeller 18
quickbooks 17
bradw 15
amessina 15
sdodson 14
kwizart 14
wolnei 14
bitlord 14
freddyw 14
remi 13
pbrobinson 13
mstevens 13
lkocman 13
misc 13
orion 12
nb 12
artkun 11
nonamedotc 10
ktdreyer 10
ajax 10
jerboaa 10
vicodan 9
po80x-nontoxic at yahoo.co.uk 9
jvanalte 9
erinn 9
cairo 8
stransky 8
greenfeld 8
sysengbd 7
petersen 7
asrob 7
akurtakov 7
ejs1920 7
jmoskovc 7
jpopelka 7
ondrejj 6
mmilata 6
mtoman 6
robatino 6
tsmetana 6
jvcelak 6
wutao85 5
nkinder 5
gtwilliams 5
till 5
kkofler 5
rcritten 5
adomurad 5
ralph 5
bruno 5
ptisnovs 5
tjikkun 5
fabiand 5
rtcm 5
rlandy 5
balay 5
brallan 5
ppisar 5
…and also 584 other reporters who created less than 5 reports each, but 867 reports combined!

1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is unimportant.

As you can see, Harald Reindl (hreindl) is completely leading this effort, and no one else is even close. Thank you, Harald!

There are lots of further names from the community. T.C. Hollingsworth (patches) provided an outstanding number of comments, followed by Akshay Vyas (akshayvyas29), mooninite, Ankur Sinha (ankursinha), Rex Dieter (rdieter), Vasileios Keramidas (keramidas), bojan, nucleo, Robert C. Lightfoot (boblfoot) and many more! Thank you, and everyone else who helped with testing Fedora updates, no matter your score.

If you are interested in helping Fedora, this is a very easy way and you can start today! Just read QA:Updates_Testing and ask any questions in #fedora-qa on IRC or test list. It would be great to see more faces around.

Thanks and enjoy the day.


When reading the statistics, please take it with a grain of salt. Not all numbers are directly comparable. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.

The heroes of Fedora 19 Alpha testing

1360095720_PrizeFedora 19 Alpha has been released. I would like to thank everyone who contributed to testing it. Here are some interesting numbers from different quality verification areas. No matter how small or large your contribution is (or whether it is listed at all), if you helped Fedora 19 Alpha quality to improve, you have our thanks.

Fedora 19 Alpha – wiki matrices

This is the list of people who filled in our release validation wiki matrices (Install, Desktop and Base), which are posted for every test compose (and release candidate) that we create. The purpose is to see which areas have been thoroughly tested and which were not.

Test period: Fedora 19 branch time – Fedora 19 Alpha release
Testers: 23
Reports: 1001
Unique referenced bugs: 69

Name Reports submitted Referenced bugs1
robatino 316 919374 924138 924244 924248 924251 924254 924255 924256 924258 924260 926913 926916 929050 929054 929177 946964 951801 (17)
boblfoot 187 922558 929373 929403 929421 946906 946951 947536 947538 948615 949906 951766 957486 957554 957783 (14)
satellit 95 923951 928287 929289 947538 948921 949761 949802 950510 951842 952250 (10)
Wutao85 91 926926 927178 947028 947031 952512 952950 (6)
nonamedotc 57 892178 (1)
adamwill 47 858270 863592 928982 947558 953329 (5)
lnie 45 951269 952950 (2)
spstarr 34 949831 951259 (2)
jskladan 27 928228 928279 948250 948719 949761 (5)
mkrizek 21 928296 948615 951039 (3)
kparal 20 928279 928287 928339 950504 950510 (5)
lkardos 17
lbrabec 10
pschindl 9 947142 950504 950510 (3)
cra 7 907058 949761 950504 (3)
tflink 5
patches 3
jsedlak 3 950641 951449 953337 (3)
mbriza 3
wolnei 1 947285 (1)
boblfoor 1
pwnall 1
jdulaney 1

1 This is a list of bug reports linked to the wiki results. They don’t have to be reported by that concrete person.

As usual, Andre Robatino (robatino) is the king of the hill 🙂 Bob Lightfoot (boblfoot) continues to be the second most active person, as in Fedora 18 Final cycle. Many thanks, guys.

I’m very glad that there are a number of community contributors at the top. Besides robatino and boblfoot, namely Thomas Gilliard (satellit), nonamedotc and Shawn Starr (spstarr) provided an amazing number of test results. The number one Red Hatter is Tao Wu (Wutao85). Great job! Of course, even the smaller numbers in the ladder are greatly appreciated and help Fedora a lot. Thank you.

Fedora 19 Alpha – Bugzilla

This is a trimmed list of people who reported bugs into Bugzilla against Fedora 19 in the specified time period. The numbers are pretty high as usual, Bugzilla is our most visible QA tool.

Test period: Fedora 19 branch time – Fedora 19 Alpha release (2013-03-12 – 2013-04-23)
Reporters: 323
New reports: 1234

Name Reports submitted1 Excess reports2 Accepted blockers3
Dhiru Kholia 103 0 (0%) 0
Adam Williamson 54 1 (1%) 7
Reartes Guillermo 29 2 (6%) 0
Andre Robatino 27 10 (37%) 12
Stef Walter 27 1 (3%) 0
Kamil Páral 25 0 (0%) 3
Jens Petersen 25 1 (4%) 0
Daniel Walsh 19 1 (5%) 0
Ľuboš Kardoš 19 1 (5%) 0
sangu 17 0 (0%) 0
John Reiser 15 0 (0%) 0
Jeff Bastian 13 1 (7%) 0
Mark Hamzy 13 1 (7%) 0
Tim Waugh 13 1 (7%) 0
Robert Lightfoot 12 4 (33%) 2
Mike FABIAN 12 1 (8%) 1
Ales Kozumplik 12 0 (0%) 0
Jan Stodola 12 0 (0%) 0
Branislav Náter 11 1 (9%) 0
Dawid Zamirski 10 0 (0%) 0
Flóki Pálsson 10 0 (0%) 0
Karsten Hopp 10 0 (0%) 0
Leslie Satenstein 10 1 (10%) 0
Vladimir Benes 10 1 (10%) 0
Zbigniew Jędrzejewski-Szmek 10 1 (10%) 0
A S Alam 9 0 (0%) 0
Jan Safranek 9 0 (0%) 0
Martin Banas 9 3 (33%) 0
Mikolaj Izdebski 9 0 (0%) 0
mussadek 9 0 (0%) 0
Tanner Doshier 9 0 (0%) 0
Alex Murray 8 0 (0%) 0
Matthew Miller 8 1 (12%) 0
Michael Schwendt 8 0 (0%) 0
Orion Poplawski 8 0 (0%) 0
Patrik Kis 8 0 (0%) 0
satellit at bendbroadband.com 8 2 (25%) 0
Petr Schindler 7 0 (0%) 2
Ankur Sinha (FranciscoD) 7 2 (28%) 0
Hans de Goede 7 1 (14%) 0
Jiří Martínek 7 0 (0%) 0
Joachim Backes 7 1 (14%) 0
Peter Robinson 7 0 (0%) 0
Peter Trenholme 7 0 (0%) 0
Brian C. Lane 6 1 (16%) 1
Alexei Panov 6 0 (0%) 0
Artem Artemov 6 0 (0%) 0
Dan Waleke 6 0 (0%) 0
Ed Greshko 6 1 (16%) 0
Elad Alfassa 6 1 (16%) 0
Harald Hoyer 6 0 (0%) 0
Jakub Dorňák 6 0 (0%) 0
Jakub Filak 6 0 (0%) 0
Jiri Popelka 6 0 (0%) 0
T.C. Hollingsworth 6 1 (16%) 0
Tao Wu 6 2 (33%) 0
Vadim Rutkovsky 6 0 (0%) 0
Shawn Starr 5 1 (20%) 1
Dan Horák 5 0 (0%) 0
Dan Mashal 5 1 (20%) 0
Dennis Gilmore 5 0 (0%) 0
Gustavo Luiz Duarte 5 0 (0%) 0
Miroslav Grepl 5 3 (60%) 0
Mr-4 5 1 (20%) 0
Ondrej Hudlicky 5 2 (40%) 0
Remi Collet 5 0 (0%) 0
Rex Dieter 5 1 (20%) 0
…and also 256 other reporters who created less than 5 reports each, but 437 reports combined!

1 The total number of new reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data.
2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable.
3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.

The most visible person here is Dhiru Kholia, who mass-reported over 100 bugs about packaging guidelines violation. When it comes to standard bug reports, the shining star here is a Red Hatter Adam Williamson. We also have quite a few community people at the top, namely Reartes Guillermo, Andre Robatino, sangu, John Reiser, Mark Hamzy, Dawid Zamirski, Flóki PálssonLeslie Satenstein and Zbigniew Jędrzejewski-Szmek. And of course there are hundreds of others, who reported just a few bugs each, but it all sums up in an amazing number of bug reports. Thank you all!

Fedora 19 Alpha – updates testing

This is a trimmed list of people who provided feedback in Bodhi for all updates proposed into Fedora 19 in the specified time period. The purpose is to make sure that broken updates do not enter the stable repository and the release continuously stabilizes.

Test period: Fedora 19 branch time – Fedora 19 Alpha release (2013-03-12 – 2013-04-23)
Testers: 98
Comments1: 278

Name Updates commented
patches 47
misc 19
akurtakov 16
raven 16
adamwill 16
kevin 15
kalev 13
pbrobinson 5
kparal 4
petersen 4
spstarr 3
mfabian 3
ankursinha 3
sharkcz 3
miketc302 3
bruno 3
deanhunter 3
robatino 3
mschwendt 3
jerboaa 2
maners 2
elad 2
twaugh 2
adomurad 2
bellet 2
ajax 2
gustavold 2
egreshko 2
mkrizek 2
boblfoot 2
yelley 2
bruce89 2
satellit 2
dwa 2
kraman 2
nucleo 2
…and also 62 other reporters who created less than 2 reports each, but 62 reports combined!

1 If a person provides multiple comments to a single update, it is considered as a single comment. Karma value is unimportant.

The top contributor is T.C. Hollingsworth (patches), who provided feedback to the most updates by far. Also from the community Piotr Drąg (raven) and Kalev Lember (kalev) were near the top as well. The most active Red Hatter was Michael Scherer (misc). There are dozens of other people who tested an update or two. Thank you all. This type of testing is very useful and very easy to participate in. It’s the best place to start if you want help Fedora QA out a bit.

Summary

The testing seems to be going well and Fedora 19 seems to go much smoother than Fedora 18 had. Thanks all contributors!

If you are interested in raising the Fedora quality up, help us out. Read QA/Join, follow the announcements and talk to us in #fedora-qa on IRC and test list. We will love to see you!


When reading the statistics, please take it with a grain of salt. The numbers are not directly comparable. People might see some reports as more valuable than others. Some people tested a lot of components, but haven’t found many problems (but that also helps). Some people used their skills in other areas than those mentioned. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by these scripts.

Testers: Use more CPUs in your VMs, you’ll get more things done

Lately I’ve found out that I can speed up my Fedora 19 testing if I increase the number of CPUs assigned to the VM. This is a short blogpost about it, maybe it will help also others.

By default, this is what a default new VM in virt-manager looks like:

vm-cpu-thumb

There is just a single CPU assigned, out of my 4 host CPUs available (Intel Core i7 processor).

In my completely unscientific benchmark, I tried changing the value and measuring how the boot time of Fedora 19 Alpha Live changes. It was measured from isolinux screen to displaying the Fedora welcome dialog. Of course I used a few warm-up starts first to make sure everything is cached and the results are not affected by the disk access. These are the results:

Fedora 19 Alpha Live boot time

Number of CPUs Boot time (seconds)
1 67
2 48
3 46
4 46

It seems that the boot process of a Live image can be well parallelized. There is a large difference between a single CPU and a dual CPU. Adding more than two CPUs doesn’t help considerably. Quite interestingly, when I tried to measure an installed system, the changes were very small:

Fedora 19 installed boot time

Number of CPUs Boot time (seconds)
1 29
2 27
3 25
4 27

The live image performs a lot of one-shot setup tasks during boot, that’s probably the major difference here.

I didn’t perform any further benchmarks inside the running system, for example Anaconda installation. It might be interesting to compare the installation speed with different number of processors, but I haven’t gotten to it yet (patches welcome:)). But because I boot Live images very often, at least I know that the boot process is significantly improved by using two CPUs in the VM. In my 4 CPU host system that seems as a good number. It doesn’t hog my host down too much, and if I really need it, I can run two VMs in parallel and they will fully utilize my processor potential, at the expense of my host system becoming a bit lagging.

As a side note, as I’ve found out, the default VM memory is 1024 MB. That is quite insufficient, your installation will suffer by a lot of swapping and it will take much longer. For pre-release images with debugging options enabled it might not even succeed. Usually I use 1.5 GB RAM for generic Fedora testing, and 2 GB RAM for pre-Beta testing (which includes debug kernel). With these amounts of memory I find the installation go pretty well. Of course you must have sufficient amount of memory available in your host system.

Also, don’t miss out on my previous blogpost about the speed of different disk bus drivers.

Happy testing!

Flattr this

How to run graphical applications with su or sudo

In this blogpost I’ll describe how to run graphical applications under a different user account in your current desktop session (i.e. without fast user switching). It involves some fiddling with the system configuration, this is not intended for general users without advanced system knowledge. The instructions are created for Fedora 18.

Everything mentioned here was discovered through a trial-and-error approach, I don’t have any expertise in this area. Some of the advice might not be fully correct. I have talked to a few qualified people and I was told that Linux doesn’t support this properly and some applications might display some glitches or not work at all. Consider this a best-effort solution – it might work perfectly for some applications, but you can’t expect it to work in general.

Some background

In my setup I have a regular user account kparal and also a second user account gamer that I use for several purposes:

  • Playing games. I use GNOME Fallback mode, so I get slightly better framerates (I have a very slow graphic card and it really makes a difference).
  • Running unknown and “not so trustworthy” tools and scripts, often downloaded somewhere from the Internet (i.e. not packaged in Fedora). I do not really expect malware in these tools, but more likely serious bugs. I like to know that the unknown script can’t delete my personal data by accident.

But using the second user account is sometimes also inconvenient:

  • If you need to transfer a piece of text (e.g. a hyperlink) from one account to the other, it involves saving it as a file, copying it and fixing permissions. Ugh.
  • If you are inside gamer session, you don’t see any notifications from your kparal‘s IM clients, mail clients, etc. You need to switch forth and back all the time to check your messages and reply.
  • If you are inside gamer session, you can’t easily access some files in your kparal home folder that you would like to, e.g. music. Just to play some background music, you need to fiddle with your data, set up permissions, etc. Boring.

Over the weekend I installed Steam. Obviously I run it under the gamer account. Not just because of performance, but also because my trust in Steam is far from being 100%. It downloads lots of external binaries and executes them. I trust Valve they are careful to not have any security incident (e.g. malware added to some of their game updates), they certainly have some security checks and policies, but how reliable are those? Does Steam executes everything inside some sandbox? I don’t know and honestly, running Steam (and dozens of third-party binaries it executes) in a separate account seems like a reasonable trade-off.

When I tried to buy a game in Steam, I needed to log in to my Moneybookers account. But my financial passwords usually consists of 20 random characters and are safely stored in a password manager in the kparal session. I got very annoyed at this point. The string is too long to remember, I was offended by the idea to write it down (what do we have technology for if I need to use paper?) and I didn’t really want to save it in a plain text file on disk. Call it a whim. So how do I transfer it? Why on earth can’t I just run steam under the gamer account inside my kparal session and copy and paste it? Windows can do it!

Well, it turns out Linux can do this too, more or less, but it needs a few tweaks. After that you can run any application under a different user account inside your desktop session. Let’s see how.

Basic application window

If you log in using su and run a sample graphical application, it should work out of the box:

kparal@kraken ~ $ su - gamer -c gcalctool
Password: 

** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

** (gcalctool:3969): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.
(repeated many times)

There are some accessibility bus warnings, but I haven’t seen any loss of functionality, so I consider them mostly harmless. The dconf errors are arguably a bug and you might lose some functionality because of that – application settings might not be loaded nor saved. If you see these errors, you should unset XDG_RUNTIME_DIR variable first:

kparal@kraken ~ $ su - gamer
Password: 
gamer@kraken ~ $ unset XDG_RUNTIME_DIR
gamer@kraken ~ $ gcalctool

 ** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

At this point most of your graphical applications should work just fine (the only problem I’ve found is that the global GNOME menu doesn’t work with them). Some of their functionality can be lost however, especially if the application tries to communicate over D-Bus with other processes. According to information I gathered, you might improve the situation in certain cases if you run the application using dbus-launch:

gamer@kraken ~ $ dbus-launch your-application

I haven’t yet seen any application where this would be required, so I can’t provide any more details. Basically if you see any errors regarding D-Bus, you can expect some loss of functionality. But often you might not care, it depends on what you need to achieve with that particular application.

Using sudo instead of su

I like to use sudo instead of su, because it caches your password and it can be even configured for password-less login. However the approach is not so straightforward here and requires more tweaking. Only follow this section if su doesn’t suit your needs.

In the basic workflow, this is what you will see using sudo command:

kparal@kraken ~ $ sudo -i -u gamer gcalctool
No protocol specified

** (gcalctool:5113): WARNING **: Could not open X display
No protocol specified

(gcalctool:5113): Gtk-WARNING **: cannot open display: :0

This is because your X server permissions do not allow anyone else to connect to it (IIUIC):

kparal@kraken ~ $ xhost
access control enabled, only authorized clients can connect
SI:localuser:kparal

If you want to use sudo instead of su, you need to allow gamer to display the window in your session. Like this:

kparal@kraken ~ $ xhost +si:localuser:gamer
localuser:gamer being added to access control list

kparal@kraken ~ $ xhost
access control enabled, only authorized clients can connect
SI:localuser:gamer
SI:localuser:kparal

Now try it again:

kparal@kraken ~ $ sudo -i -u gamer gcalctool

The calculator should appear just fine. The xhost command has to be executed after each session start, so I wanted to add it to ~kparal/.xprofile, but then I found out that Fedora doesn’t source that file. I added it to ~kparal/.profile instead like this:

# allow gamer to display apps on this X server
# (don't do that for local non-X and any remote connections)
if [ -n "$DISPLAY" -a -z "$SSH_CLIENT" ]; then
    xhost +si:localuser:gamer
fi

I now used the command above to run Steam in my session and paste in the Moneybookers login credentials conveniently. Success!

Sound

I quickly found out that sound is not routed for these redirected applications. It’s a pity it doesn’t work out of the box, but fortunately it can be fixed quite easily.

First, install and run paprefs and activate Enable network access to local sound devices. I have no idea which configuration was adjusted, because nothing changed neither in ~/.pulse nor in /etc/pulse. But you can see now the pulseaudio server listening over TCP/IP for network connections. Authorization should be required, so you don’t need to be afraid of eavesdroppers.

Now, try to play some sound:

kparal@kraken ~ $ su - gamer -c paplay /usr/share/sounds/alsa/Front_Center.wav

(or just run Totem/Firefox/etc)

If you are lucky (unlike me), your audio now works out of the box. But if you pulseaudio daemon is restarted for any reason (it crashes or you kill it and start again), the routing no longer works and you need to re-log to your desktop session. Probably a bug. I didn’t know that, so I spent hours reading PulseAudio documentation. It’s not the most thrilling experience.

If that magic routing didn’t work for you, or you need to play audio even after PA is restarted, this is what I involuntarily discovered:

  1. You can copy ~kparal/.pulse-cookie to ~gamer/.pulse-cookie (and re-assign file ownership). That will handle authentication.
  2. Then you can forward audio by sudoing to gamer, exporting PULSE_SERVER=localhost variable and running the app you wish.

(It should be also possible to route the audio using unix sockets (instead of TCP/IP sockets), but the damned documentation is not helpful at all in achieving this task.)

Graphical acceleration

Spot two differences:

kparal@kraken ~ $ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset

and

kparal@kraken ~ $ su - gamer -c glxinfo | grep render
Password:
libGL error: failed to load driver: i965
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)

Yes, your redirected applications don’t have 3D acceleration. Here is a more detailed error message:

kparal@kraken ~ $ su - gamer
Password:
gamer@kraken ~ $ LIBGL_DEBUG=verbose glxinfo | grep render
libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: Can't open configuration file /home/gamer/.drirc: No such file or directory.
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)

I tried to run chromium-bsu and extremetuxracer, both run around 30 FPS using software rendering. Not suitable to gaming at all.

Fortunately I’ve found out the reason. It’s all about access permissions to /dev/dri/card0 file, which represents your graphics card. If you log in using a standard graphical session, some daemon (probably logind) grants you temporary rw access to that file using ACLs:

kparal@kraken ~ $ getfacl /dev/dri/card0 
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video
user::rw-
user:kparal:rw-
group::rw-
mask::rw-
other::---

But if you log in using su or sudo, you are not given proper permissions. I have found two solutions. The first one is to manually add gamer‘s ACLs after each boot:

kparal@kraken ~ $ sudo setfacl -m user:gamer:rw /dev/dri/card0

This can be added for example to /etc/rc.d/rc.local in order to be executed every boot. The other approach is to add gamer to the video group, which owns the file. In this case you don’t need to execute anything else on each boot, the change is permanent.

Now your 3D applications should work correctly:

kparal@kraken ~ $ su - gamer -c glxinfo | grep render
Password:
direct rendering: Yes
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset

The simple games I tried now run at full speed.

Please note however, that there are slight security concerns when you elevate these permissions for gamer permanently. If the account gets hacked, the attacker can access your graphics card (maybe see your display? I don’t know) or even a camera (just if you used the video group approach, because this group also controls access to the webcam) while being logged in remotely. From this reason the first approach seems a bit safer to me (limits the number of devices) and you should definitely prohibit gamer from any remote access (e.g. disable this account in your ssh server configuration).

Epilogue

That’s it, I can finally display graphical applications (even games) from a different user account inside my desktop session. It took me quite some time to find this all out. It’s highly probable that I did a lot of things the wrong way. Does anybody know of a tool that would handle all this setup transparently and easily? Or does anyone know a working sandbox tool that would fit these use cases? Please share your improvements in the comments. Thanks.

Flattr this

The heroes of Fedora 18 Final testing – Bugzilla

1360095720_PrizeIt took me a while, but finally I have further data regarding Fedora 18 Final testing contributors. Last time I presented a list of people who helped out with QA wiki matrices, this time I have Bugzilla statistics.

The results are pretty interesting. Over 800 people reported bugs between Fedora 18 Beta and Final, creating over 2300 new bugs in total. Those are stunning numbers for a 6-week period including Christmas holidays. A trimmed list of top contributors is below:

Test period: 2012-11-29 – 2013-01-15 (Fedora 18 Beta release – Fedora 18 Final release)
Total number of reporters: 814
Total number of new reports: 2311

Name Total reports submitted1 Excess reports2 Accepted blockers3
Michael Scherer 59 1 (1%) 0
Reartes Guillermo 53 3 (5%) 0
Mikhail 43 5 (11%) 0
Jan Teichmann 34 28 (82%) 0
Kamil Páral 31 2 (6%) 2
Steve Tyler 29 0 (0%) 3
Aleksandar Kostadinov 29 7 (24%) 0
Chris Murphy 25 0 (0%) 7
Gene Czarcinski 25 2 (8%) 0
Adam Williamson 24 0 (0%) 5
Dean Hunter 24 11 (45%) 0
Kay Sievers 22 3 (13%) 0
Michal Schmidt 19 1 (5%) 0
Heiko Adams 18 3 (16%) 0
Max 18 0 (0%) 0
Andre Robatino 17 15 (88%) 0
Florian Weimer 17 1 (5%) 0
Štefan Gurský 17 0 (0%) 0
Niki Guldbrand 16 0 (0%) 0
bob 14 3 (21%) 0
Flóki Pálsson 14 2 (14%) 0
mariolinux at alice.it 14 0 (0%) 0
Braden McDaniel 13 2 (15%) 0
Cole Robinson 12 1 (8%) 0
Brian J. Murrell 11 0 (0%) 0
Mikolaj Izdebski 11 0 (0%) 0
Petr Schindler 10 0 (0%) 1
Bryce 10 2 (20%) 0
Eugene 10 0 (0%) 0
IBM Bug Proxy 10 0 (0%) 0
Sergio 10 1 (10%) 0
Jan Vcelak 9 0 (0%) 1
Tommy He 9 0 (0%) 1
Carlos Soriano 9 1 (11%) 0
Hin-Tak Leung 9 0 (0%) 0
Lingzhu Xiang 9 0 (0%) 0
Michael Schwendt 9 2 (22%) 0
mkruger 9 3 (33%) 0
sheepdestroyer at gmail.com 9 0 (0%) 0
Tim Waugh 9 0 (0%) 0
xset1980 at hotmail.com 9 2 (22%) 0
Matthew Miller 8 1 (12%) 2
abyss.7 at gmail.com 8 1 (12%) 0
Ankur Sinha (FranciscoD) 8 0 (0%) 0
D. Charles Pyle 8 0 (0%) 0
Dan Mashal 8 0 (0%) 0
Jean-François Fortin Tam 8 0 (0%) 0
Leslie Satenstein 8 1 (12%) 0
Luya Tshimbalanga 8 2 (25%) 0
M. Edward (Ed) Borasky 8 0 (0%) 0
Miro Hrončok 8 1 (12%) 0
Munteanu Victor Ion 8 0 (0%) 0
Mustafa 8 1 (12%) 0
pizza306 at gmail.com 8 2 (25%) 0
quickbooks.office at gmail.com 8 0 (0%) 0
Richard W.M. Jones 8 1 (12%) 0
Sigitas 8 0 (0%) 0
skkd.h4k1n9 at yahoo.de 8 0 (0%) 0
Eric Blake 7 0 (0%) 1
Ian Pilcher 7 0 (0%) 1
m-redhat at fuglos.org 7 0 (0%) 1
Robert Lightfoot 7 4 (57%) 1
cornel panceac 7 0 (0%) 0
Erwan Bousse 7 1 (14%) 0
Joachim Backes 7 2 (28%) 0
Mikko Tiihonen 7 0 (0%) 0
Amit Shah 6 2 (33%) 0
Boricua 6 0 (0%) 0
Dave Jones 6 2 (33%) 0
Guillaume AMAT 6 1 (16%) 0
Ivo Sarak 6 0 (0%) 0
Jaroslav Škarvada 6 0 (0%) 0
Jens Petersen 6 0 (0%) 0
Klaus Lichtenwalder 6 0 (0%) 0
Martin Holec 6 1 (16%) 0
Matthias Runge 6 0 (0%) 0
Milan Bouchet-Valat 6 0 (0%) 0
mussadek 6 0 (0%) 0
nero 6 1 (16%) 0
Philipp Dreimann 6 0 (0%) 0
Tapani Björg 6 1 (16%) 0
W. Michael Petullo 6 0 (0%) 0
A.J. Werkman 5 0 (0%) 0
Benjamin Kosnik 5 0 (0%) 0
Brandon 5 1 (20%) 0
Christoph Frieben 5 0 (0%) 0
cookies.river at gmail.com 5 0 (0%) 0
Fabrice Bellet 5 1 (20%) 0
Francesco Frassinelli 5 1 (20%) 0
Gerard Ryan 5 0 (0%) 0
Gustavo Luiz Duarte 5 0 (0%) 0
Jan Sedlák 5 1 (20%) 0
Jared Smith 5 0 (0%) 0
Josh Boyer 5 0 (0%) 0
leigh scott 5 1 (20%) 0
Luke Macken 5 0 (0%) 0
mastaiza 5 0 (0%) 0
Nicholas Nachefski 5 0 (0%) 0
Orion Poplawski 5 2 (40%) 0
Pravin Satpute 5 0 (0%) 0
Ralf Corsepius 5 1 (20%) 0
Rex Dieter 5 1 (20%) 0
Sam Tygier 5 0 (0%) 0
satellit at bendbroadband.com 5 0 (0%) 0
…and also 710 other reporters who created less than 5 reports each, but 1164 reports combined!

1 The total number of new reports (including “excess reports”). Reopened reports or reports with a changed version are not included, because it was not technically easy to retrieve those. This is one of the reasons why you shouldn’t take the numbers too seriously, but just as interesting and fun data.
2 Excess reports are those that were closed as NOTABUG, WONTFIX, WORKSFORME, CANTFIX or INSUFFICIENT_DATA. Excess reports are not necessarily a bad thing, but they make for interesting statistics. Close manual inspection is required to separate valuable excess reports from those which are less valuable.
3 This only includes reports that were created by that particular user and accepted as blockers afterwards. The user might have proposed other people’s reports as blockers, but this is not reflected in this number.

I’m very glad to see that most of the top reporters are in fact not Red Hat employees. That suggests how strong Fedora community is. I’d like to specifically thank these top community contributors, namely Reartes Guillermo, Mikhail, Jan Teichmann, Steve Tyler, Chris Murphy, Gene Czarcinski, Dean Hunter, Heiko Adams, Max, Andre Robatino, Štefan Gurský, Niki Guldbrand and all the others that spent their personal time to help improve Fedora quality.

Of course, kudos also to anyone else who contributed, no matter whether they are mentioned in the matrix above or not. Without you, the bug reporters, we wouldn’t be able to keep Fedora 18 quality up, as it is (hopefully) now. So, thank you!

Recruitment pitch: If you haven’t participated in Fedora 18 release validation, we would love to see you in the Fedora 19 cycle (the test period will start in a month or so) or simply helping out to polish the currently stable Fedora 18 release. Please read QA/Join#Reporting_bugs_in_Fedora_releases, follow the announcements and talk to us in #fedora-qa on IRC and test list.

Thanks everyone!


When reading the statistics, please take it with a grain of salt. The numbers are not directly comparable. People might see some reports as more valuable than others. Some people tested a lot of components, but haven’t found many problems (but that also helps). Some people used their skills in other areas than Bugzilla or wiki matrices. This is not meant to be a comparison chart, but a well-meant “thank you” letter.
The statistics were generated by the stats-bugzilla.py script.