[opensuse-packaging] Desktop categories: mismatch in brp-desktop and rpmlint
Hi, I have a problem with a desktop file. The upstream one has Categories=Application;AudioVideo; but brp-desktop stops the build with Insufficient Category. ERROR: No sufficient Category definition: /var/tmp/playitslowly-1.1.0- build//usr/share/applications/playitslowly.desktop Errors in installed desktop file detected. Please mail stbinner@suse.de, if you think this is wrong. error: Bad exit status from /var/tmp/rpm-tmp.79930 (%install) So I changed it according SUSE Packaging Conventions [1] to Categories=Multimedia;Player;AudioVideo;AudioVideoPlayer; but now I got a rpmlint warning: playitslowly.x86_64: W: invalid-desktopfile /usr/share/applications/playitslowly.desktop value "Multimedia;Player;AudioVideo;AudioVideoPlayer;" for key "Categories" in group "Desktop Entry" contains an unregistered value "Multimedia"; values extending the format should start with "X-" /tmp/playitslowly-1.1.0-1.x86_64.rpm.23739/usr/share/applications/playitslowly.desktop: .desktop file is not valid, check with desktop-file-validate So what should be in Categories which will pass brp-desktop and rpmlint checks? And is there any reason why we have a double check of the same thing? [1] http://en.opensuse.org/SUSE_Package_Conventions/Desktop_Menu#9.4.6._Multimed... Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Montag 26 Januar 2009 schrieb Michal Vyskocil:
Hi,
I have a problem with a desktop file. The upstream one has
Categories=Application;AudioVideo;
but brp-desktop stops the build with Insufficient Category.
ERROR: No sufficient Category definition: /var/tmp/playitslowly-1.1.0- build//usr/share/applications/playitslowly.desktop Errors in installed desktop file detected. Please mail stbinner@suse.de, if you think this is wrong. error: Bad exit status from /var/tmp/rpm-tmp.79930 (%install)
So I changed it according SUSE Packaging Conventions [1] to
Categories=Multimedia;Player;AudioVideo;AudioVideoPlayer;
but now I got a rpmlint warning: playitslowly.x86_64: W: invalid-desktopfile /usr/share/applications/playitslowly.desktop value "Multimedia;Player;AudioVideo;AudioVideoPlayer;" for key "Categories" in group "Desktop Entry" contains an unregistered value "Multimedia"; values extending the format should start with "X-" /tmp/playitslowly-1.1.0-1.x86_64.rpm.23739/usr/share/applications/playitslo wly.desktop: .desktop file is not valid, check with desktop-file-validate
So what should be in Categories which will pass brp-desktop and rpmlint checks? And is there any reason why we have a double check of the same thing?
It's not the same. rpmlint checks if the .desktop file is correct according to the xdg standard (e.g. lists only valid categories). brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 26 Jan 2009, Stephan Kulow wrote:- <snip>
It's not the same. rpmlint checks if the .desktop file is correct according to the xdg standard (e.g. lists only valid categories).
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
I get the same error for a package I'm trying to build on 11.1. The
package I'm building isn't yet on the build service, as I want to make
sure it builds locally before moving it to the build service. The error
I've receiving is the same "No sufficient Category definition" even
though the category is the same one as used as the example for Education
Categories:
On Sat, 7 Feb 2009, David Bolt wrote:- <snip> I've found what was causing my problem. I was using the exact example text on: URL:http://en.opensuse.org/SUSE_Package_Conventions/Desktop_Menu#9.4.2._Educ... which is: Category=Education;Astronomy; as this matched the categories I required. Only, the example is wrong, and it should be: Categories=Education;Astronomy; instead. The examples have now been fixed. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s | openSUSE 10.3 32b | openSUSE 11.0 32b | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.6 | RISC OS 3.11 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 26 Jan 2009, Stephan Kulow wrote:- <snip>
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
Purely out of curiosity, I've built up a list of all the desktop categories using those in the openSUSE packaging guidelines and those listed on freedesk.org. I've then tested whether they are valid using desktop-file-validate test and also whether they pass the rpmlint checks[0]. I've considered adding the list to the wiki but wondered if anyone has a good idea where it should be placed, and where to add links pointing to it. I've broken the list down into a series of tables. The checked categories are: Invalid categories that are listed as available in openSUSE[1]; Reserved categories; Valid categories; ConsoleOnly categories; GTK categories; GTK;Gnome categories; Qt categories; Qt;KDE categories; Motif categories; Java categories; The tables are temporarily available through my site at this location: URL:http://www.davjam.org/~davjam/linux/desktop_categories.php [0] Also, as an assist for those building cross-distro packages, I've worked through the same list to see which ones Fedora appears to support. I'll probably do the same test again once 11.2 goes into beta just to keep it up to date. [1] Funnily, there are presently three categories listed in the openSUSE Packaging Guidelines that both fail validation and cause RPM builds to abort: AudioVideo;Jukebox; Game;3DGame; Utility;XMLUtility; Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s | openSUSE 10.3 32b | openSUSE 11.0 32b | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.6 | RISC OS 3.11 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
David Bolt wrote:
On Mon, 26 Jan 2009, Stephan Kulow wrote:-
<snip>
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
It indicates several errors in the check (and very probably in menu definitions). Please open a bug in Bugzilla. SuSE specific categories without initial X- should not exist. Note that Freedesktop itself has a problem with definition of Education and Science. I see no reason why Geology can be used with Science but Geography cannot be used with. Did you use any tool to parse Freedesktop spec and create a list? Maybe it could be useful as well. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le samedi 14 février 2009, à 23:20 +0000, David Bolt a écrit :
On Mon, 26 Jan 2009, Stephan Kulow wrote:-
<snip>
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
Purely out of curiosity, I've built up a list of all the desktop categories using those in the openSUSE packaging guidelines and those listed on freedesk.org. I've then tested whether they are valid using desktop-file-validate test and also whether they pass the rpmlint checks[0]. I've considered adding the list to the wiki but wondered if anyone has a good idea where it should be placed, and where to add links pointing to it.
FWIW, I'm more and more convinced that we should just remove all X-SuSE-* categories and only use the ones in the specifications. [1] We can fix the spec where it needs to be fixed. The first step would be to change /etc/xdg/menus/applications.menus to only use upstream categories. It's a long-term effort, but I think we can still fix this during 11.2 if we want since we have quite some time before the release. Vincent [1] There might be a few cases where we'd still really really really need a custom category, but right now it's hard to know. -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Montag 16 Februar 2009 schrieb Vincent Untz:
Le samedi 14 février 2009, à 23:20 +0000, David Bolt a écrit :
On Mon, 26 Jan 2009, Stephan Kulow wrote:-
<snip>
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
Purely out of curiosity, I've built up a list of all the desktop categories using those in the openSUSE packaging guidelines and those listed on freedesk.org. I've then tested whether they are valid using desktop-file-validate test and also whether they pass the rpmlint checks[0]. I've considered adding the list to the wiki but wondered if anyone has a good idea where it should be placed, and where to add links pointing to it.
FWIW, I'm more and more convinced that we should just remove all X-SuSE-* categories and only use the ones in the specifications. [1] We can fix the spec where it needs to be fixed.
The first step would be to change /etc/xdg/menus/applications.menus to only use upstream categories.
It's a long-term effort, but I think we can still fix this during 11.2 if we want since we have quite some time before the release.
What's the benefit for either us or the user? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 17 février 2009, à 11:02 +0100, Stephan Kulow a écrit :
Am Montag 16 Februar 2009 schrieb Vincent Untz:
Le samedi 14 février 2009, à 23:20 +0000, David Bolt a écrit :
On Mon, 26 Jan 2009, Stephan Kulow wrote:-
<snip>
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
Purely out of curiosity, I've built up a list of all the desktop categories using those in the openSUSE packaging guidelines and those listed on freedesk.org. I've then tested whether they are valid using desktop-file-validate test and also whether they pass the rpmlint checks[0]. I've considered adding the list to the wiki but wondered if anyone has a good idea where it should be placed, and where to add links pointing to it.
FWIW, I'm more and more convinced that we should just remove all X-SuSE-* categories and only use the ones in the specifications. [1] We can fix the spec where it needs to be fixed.
The first step would be to change /etc/xdg/menus/applications.menus to only use upstream categories.
It's a long-term effort, but I think we can still fix this during 11.2 if we want since we have quite some time before the release.
What's the benefit for either us or the user?
Us: we can stop tweaking the categories of all desktop files to try to make them appear at the right place, and just let upstream do it the right way. It's a real pain right now... Especially since sometimes, you don't even notice that your .desktop file doesn't even appear anywhere (happened to me last week, after a package update). The user: no real benefit. (well, I could give you this one: similar experience in openSUSE menus as in the menus of other distros; better consistency = better docs) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Us: we can stop tweaking the categories of all desktop files to try to make them appear at the right place, and just let upstream do it the right way. It's a real pain right now... Especially since sometimes, you don't even notice that your .desktop file doesn't even appear anywhere (happened to me last week, after a package update). From my experience: upstream does not care how a merged menu looks like. The xteddy author only checks in fvwm's menu, gnome upstream only checks if a gnome menu alone looks ok, same for kde upstream. and it doesn't matter to either of them if they use the categories the same way. Because "System" doesn't mean the same to everyone. So I think it will create a regression to
Am Dienstag 17 Februar 2009 schrieb Vincent Untz: the user with little gain for us. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Vincent Untz wrote:
Le samedi 14 février 2009, à 23:20 +0000, David Bolt a écrit :
On Mon, 26 Jan 2009, Stephan Kulow wrote:-
<snip>
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
Purely out of curiosity, I've built up a list of all the desktop categories using those in the openSUSE packaging guidelines and those listed on freedesk.org. I've then tested whether they are valid using desktop-file-validate test and also whether they pass the rpmlint checks[0]. I've considered adding the list to the wiki but wondered if anyone has a good idea where it should be placed, and where to add links pointing to it.
FWIW, I'm more and more convinced that we should just remove all X-SuSE-* categories and only use the ones in the specifications. [1] We can fix the spec where it needs to be fixed.
Yes, http://standards.freedesktop.org/menu-spec/latest/apa.html definitely needs to be fixed: - Allowing Science as a main category without Education. - Not forcing sciences to be Education (e. g. Geography, Economy,...) - Classify mapping software and map editing software. It is Graphics, Geoscience, 2DGraphics, or Geography? Should we create Maps category? As it is a popular type of software, we need to say it explicitly. - PIM may be useful category (probably secondary for Office). - Allow toolkit categories GPE and XFCE. - Finally provide a decision for Religious/Spiritual software to prevent yet another flamewar on XDG list. - Create a menu lint tool directly associated with the specification. It can be just a set of desktop files with all allowed combinations and a tool checking for match and checking that desktop-file-validate processes it correctly. The link on the beginning of this thread is a good start. - Create bugzilla account at freedesktop.org for the menu spec. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Stephan Kulow wrote:
Am Dienstag 17 Februar 2009 schrieb Vincent Untz:
Us: we can stop tweaking the categories of all desktop files to try to make them appear at the right place, and just let upstream do it the right way. It's a real pain right now... Especially since sometimes, you don't even notice that your .desktop file doesn't even appear anywhere (happened to me last week, after a package update). From my experience: upstream does not care how a merged menu looks like. The xteddy author only checks in fvwm's menu, gnome upstream only checks if a gnome menu alone looks ok, same for kde upstream. and it doesn't matter to either of them if they use the categories the same way.
Purpose of Freedesktop design: Upstream should care about Categories, downstream should care about Categories -> menu mapping. In an ideal case everything should work out of the box for all applications. In a real world it does not. We should: - Push our Categories fixes to upstream. - Help upstream to display correctly in all menus. - We need a way to change the specification, if it will be needed. - learn upstream to call desktop-file-validate (or even implement this in e. g. INTLTOOL_DESKTOP_RULE (in /usr/share/aclocal/intltool.m4).
Because "System" doesn't mean the same to everyone. So I think it will create a regression to the user with little gain for us.
That is why there is a specification: http://standards.freedesktop.org/menu-spec/latest/apa.html -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 16 Feb 2009, Stanislav Brabec wrote:-
David Bolt wrote:
On Mon, 26 Jan 2009, Stephan Kulow wrote:-
<snip>
brp-desktop checks if the desktop file will map to one of our menu structures. And according to /etc/xdg/menus/applications.menu the category is X-SuSE-Core-Multimedia, but AudiVideo already maps there.
It indicates several errors in the check (and very probably in menu definitions).
Please open a bug in Bugzilla.
SuSE specific categories without initial X- should not exist.
Was that aimed at the OP, Stephan or myself? I'm guessing it was for the OP or Stephan.
Note that Freedesktop itself has a problem with definition of Education and Science. I see no reason why Geology can be used with Science but Geography cannot be used with.
That is a little strange, and something I hadn't noticed before. However, while it's listed as being under Education; it is still allowed under (*;)Education;Science; according to desktop-file-validate. I have wondered why ImageProcessing appears to be allowed for Education;Science; but doesn't appear to be so for either Graphics or Office. Checking them shows them to be valid and, although they pass the checks for Fedora, fail on openSUSE 11.1. I'm not overly good at reading source code, but looking at the source for desktop-file-validate, specifically validate.c, it certainly looks like any combination of main categories and additional categories are valid. I've added a few of test category combinations to check this. The combinations were (*;)Graphics;ImageProcessing; (*;)Office;ImageProcessing; (*;)Network;VectorGraphics;Sequencer; ConsoleOnly;Network;VectorGraphics;Sequencer;Clock; The last two were the real test combinations. As I expected, they all fail the rpmlint check when built on openSUSE but all four do pass as valid combinations and they all build and pass rpmlint checks on Fedora. I haven't installed any of them as yet so I have no idea where in their desktop menu the "applications" would end up.
Did you use any tool to parse Freedesktop spec and create a list? Maybe it could be useful as well.
No, I compiled the lists of Freedesk and openSUSE categories manually. I did use a script to create a desktop file for each of the listed categories, test for validity[0], and then build a source RPM including the desktop file, a simple icon and dummy script. After that, I used my wrapper for the build script, to perform clean builds. As my wrapper checks to see if a build was successful and removes the source package/spec from /usr/src/packages/SOURCES if it is, those that were left behind after it had completed its run through must have failed to build. I then manually entered them into a database[1], which is then used to generate the list on my web site. [0] And just to make sure I could identify those that failed validation, I gave them a different version number to those that passed. [1] I should really automate that part. The build test on Fedora 10 doesn't need manual intervention. I use a single command line that does the build, checks the results and updates the database with the results of each package build. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s | openSUSE 10.3 32b | openSUSE 11.0 32b | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.6 | RISC OS 3.11 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
David Bolt wrote:
Note that Freedesktop itself has a problem with definition of Education and Science. I see no reason why Geology can be used with Science but Geography cannot be used with.
That is a little strange, and something I hadn't noticed before. However, while it's listed as being under Education; it is still allowed under (*;)Education;Science; according to desktop-file-validate.
With exception of Geography, Economy and few others you can. But having a tools for PCB design, Fourier analysis in the menu called "School as a playground" does not look well: https://bugzilla.novell.com/show_bug.cgi?id=443364
I have wondered why ImageProcessing appears to be allowed for Education;Science; but doesn't appear to be so for either Graphics or Office. Checking them shows them to be valid and, although they pass the checks for Fedora, fail on openSUSE 11.1.
It may be another valid point for the next spec. Vincent, is there any Desktop Menu spec problems tracker?
I'm not overly good at reading source code, but looking at the source for desktop-file-validate, specifically validate.c, it certainly looks like any combination of main categories and additional categories are valid. I've added a few of test category combinations to check this. The combinations were
Then it is probably less strict than the spec. IMHO the spec should be considered as correct => Valid combinations must have menu mapping, invalid combinations should cause an error. And I think, that we need an utility desktop-menu-validate, that should complain: Error: Your menu lacks support for Development;Engineering... It would force all vendors to use menu system that places correctly all correct desktop files. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Tue, 17 Feb 2009, Stanislav Brabec wrote:- <Snip>
- Create a menu lint tool directly associated with the specification. It can be just a set of desktop files with all allowed combinations and a tool checking for match and checking that desktop-file-validate processes it correctly.
My latest checks of desktop-file-validate shows it doesn't appear to do very much checking as far as category combinations are concerned. As long as there are no invalid categories, and there's at least one main category and one additional category, then basically any combination of categories will pass validation.
The link on the beginning of this thread is a good start.
Well, apart from the test combinations, the list should be a pretty good starter. I've marked those additional ones as test combinations and put them into a separate table. Regards, David Bolt -- Team Acorn: http://www.distributed.net/ OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s | openSUSE 10.3 32b | openSUSE 11.0 32b | openSUSE 10.2 64b | openSUSE 10.3 64b | openSUSE 11.0 64b | openSUSE 11.1 64b TOS 4.02 | openSUSE 10.3 PPC | RISC OS 3.6 | RISC OS 3.11 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le mardi 17 février 2009, à 17:40 +0100, Stanislav Brabec a écrit :
It may be another valid point for the next spec. Vincent, is there any Desktop Menu spec problems tracker?
http://bugs.freedesktop.org/enter_bug.cgi?product=Specifications (sure, there's only one component, but let's ignore that for now) Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Vincent Untz wrote:
Le mardi 17 février 2009, à 17:40 +0100, Stanislav Brabec a écrit :
It may be another valid point for the next spec. Vincent, is there any Desktop Menu spec problems tracker?
http://bugs.freedesktop.org/enter_bug.cgi?product=Specifications
(sure, there's only one component, but let's ignore that for now)
OK. Problems described here reported as: http://bugs.freedesktop.org/show_bug.cgi?id=20189 http://bugs.freedesktop.org/show_bug.cgi?id=20186 I have also collected some of long-standing issues from the XDG list. desktop-file-utils bug report will be done as well. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (5)
-
David Bolt -
Michal Vyskocil -
Stanislav Brabec -
Stephan Kulow -
Vincent Untz