[libvirt] [PATCH v2] maint: Switch to xz compressed PAX release archives
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. --- Changes from [v1]: * Update all references to .tar.gz, including spec files, scripts and documentation (thanks Dan) * Fix typo lenght -> length (thanks Ján) [v1] https://www.redhat.com/archives/libvir-list/2016-June/msg00974.html .gitignore | 2 +- Makefile.am | 2 +- autobuild.sh | 2 +- configure.ac | 2 +- docs/compiling.html.in | 2 +- docs/downloads.html.in | 4 ++-- libvirt.spec.in | 2 +- mingw-libvirt.spec.in | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-) diff --git a/.gitignore b/.gitignore index 7fd9963..39c0423 100644 --- a/.gitignore +++ b/.gitignore @@ -88,7 +88,7 @@ /gnulib/tests/* /include/libvirt/libvirt-common.h /libtool -/libvirt-*.tar.gz +/libvirt-*.tar.xz /libvirt-[0-9]* /libvirt*.pc /libvirt.spec diff --git a/Makefile.am b/Makefile.am index da07e6c..4b4aad3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -63,7 +63,7 @@ $(top_srcdir)/HACKING: $(top_srcdir)/docs/hacking1.xsl \ > $@-t && mv $@-t $@ ; fi; rpm: clean - @(unset CDPATH ; $(MAKE) dist && rpmbuild -ta $(distdir).tar.gz) + @(unset CDPATH ; $(MAKE) dist && rpmbuild -ta $(distdir).tar.xz) check-local: all tests diff --git a/autobuild.sh b/autobuild.sh index 4d9f616..2143479 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -56,7 +56,7 @@ exec 3>&- test "$st" = 0 test -x /usr/bin/lcov && make cov -rm -f *.tar.gz +rm -f *.tar.xz make dist if test -n "$AUTOBUILD_COUNTER" ; then diff --git a/configure.ac b/configure.ac index 0114149..7d16e5a 100644 --- a/configure.ac +++ b/configure.ac @@ -24,7 +24,7 @@ AH_BOTTOM([#include <config-post.h>]) AC_CONFIG_MACRO_DIR([m4]) dnl Make automake keep quiet about wildcards & other GNUmake-isms; also keep dnl quiet about the fact that we intentionally cater to automake 1.9 -AM_INIT_AUTOMAKE([-Wno-portability -Wno-obsolete tar-ustar subdir-objects]) +AM_INIT_AUTOMAKE([-Wno-portability -Wno-obsolete tar-pax no-dist-gzip dist-xz subdir-objects]) dnl older automake's default of ARFLAGS=cru is noisy on newer binutils; dnl we don't really need the 'u' even in older toolchains. Then there is dnl older libtool, which spelled it AR_FLAGS diff --git a/docs/compiling.html.in b/docs/compiling.html.in index aff5487..d2a3f15 100644 --- a/docs/compiling.html.in +++ b/docs/compiling.html.in @@ -13,7 +13,7 @@ </p> <pre> - $ gunzip -c libvirt-x.x.x.tar.gz | tar xvf - + $ xz -c libvirt-x.x.x.tar.xz | tar xvf - $ cd libvirt-x.x.x $ ./configure</pre> diff --git a/docs/downloads.html.in b/docs/downloads.html.in index f213b29..1a3400a 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -28,8 +28,8 @@ </p> <ul> - <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz">libvirt.org FTP server</a></li> - <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.gz">libvirt.org HTTP server</a></li> + <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.xz">libvirt.org FTP server</a></li> + <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.xz">libvirt.org HTTP server</a></li> </ul> <h2><a name="schedule">Primary release schedule</a></h2> diff --git a/libvirt.spec.in b/libvirt.spec.in index ee6162e..6b3e888 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -225,7 +225,7 @@ URL: http://libvirt.org/ %if %(echo %{version} | grep -o \\. | wc -l) == 3 %define mainturl stable_updates/ %endif -Source: http://libvirt.org/sources/%{?mainturl}libvirt-%{version}.tar.gz +Source: http://libvirt.org/sources/%{?mainturl}libvirt-%{version}.tar.xz Requires: libvirt-daemon = %{version}-%{release} Requires: libvirt-daemon-config-network = %{version}-%{release} diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index 6f95832..e808839 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -30,7 +30,7 @@ Summary: MinGW Windows libvirt virtualization library License: LGPLv2+ Group: Development/Libraries URL: http://libvirt.org/ -Source0: ftp://libvirt.org/libvirt/libvirt-%{version}.tar.gz +Source0: ftp://libvirt.org/libvirt/libvirt-%{version}.tar.xz BuildRequires: mingw32-filesystem >= 95 BuildRequires: mingw64-filesystem >= 95 -- 2.5.5
On 06/15/2016 09:03 AM, Andrea Bolognani wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. ---
I just want to point out that the tarfile is built every time you run "make rpm" (which I do quite a lot - I prefer installing rpms to the carnage created by make install), and this increases the time for make rpm on my system by 1min38sec. (jtomko may have something to say about that, since he's been interested in shaving fractions of a second off the build time in the last few days :-O) Am I going to need to carry a local patch to revert this so that I don't get *even more* bored waiting for builds to complete? Or is there a reasonable way to make it easily configurable with a switch to autogen? (even then I would still need a patch to the specfile, unless we could make it happen based on some environment setting). (Aside from that, I applied the patch and it does work).
Changes from [v1]:
* Update all references to .tar.gz, including spec files, scripts and documentation (thanks Dan) * Fix typo lenght -> length (thanks Ján)
[v1] https://www.redhat.com/archives/libvir-list/2016-June/msg00974.html
.gitignore | 2 +- Makefile.am | 2 +- autobuild.sh | 2 +- configure.ac | 2 +- docs/compiling.html.in | 2 +- docs/downloads.html.in | 4 ++-- libvirt.spec.in | 2 +- mingw-libvirt.spec.in | 2 +- 8 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/.gitignore b/.gitignore index 7fd9963..39c0423 100644 --- a/.gitignore +++ b/.gitignore @@ -88,7 +88,7 @@ /gnulib/tests/* /include/libvirt/libvirt-common.h /libtool -/libvirt-*.tar.gz +/libvirt-*.tar.xz /libvirt-[0-9]* /libvirt*.pc /libvirt.spec diff --git a/Makefile.am b/Makefile.am index da07e6c..4b4aad3 100644 --- a/Makefile.am +++ b/Makefile.am @@ -63,7 +63,7 @@ $(top_srcdir)/HACKING: $(top_srcdir)/docs/hacking1.xsl \ > $@-t && mv $@-t $@ ; fi;
rpm: clean - @(unset CDPATH ; $(MAKE) dist && rpmbuild -ta $(distdir).tar.gz) + @(unset CDPATH ; $(MAKE) dist && rpmbuild -ta $(distdir).tar.xz)
check-local: all tests
diff --git a/autobuild.sh b/autobuild.sh index 4d9f616..2143479 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -56,7 +56,7 @@ exec 3>&- test "$st" = 0 test -x /usr/bin/lcov && make cov
-rm -f *.tar.gz +rm -f *.tar.xz make dist
if test -n "$AUTOBUILD_COUNTER" ; then diff --git a/configure.ac b/configure.ac index 0114149..7d16e5a 100644 --- a/configure.ac +++ b/configure.ac @@ -24,7 +24,7 @@ AH_BOTTOM([#include <config-post.h>]) AC_CONFIG_MACRO_DIR([m4]) dnl Make automake keep quiet about wildcards & other GNUmake-isms; also keep dnl quiet about the fact that we intentionally cater to automake 1.9 -AM_INIT_AUTOMAKE([-Wno-portability -Wno-obsolete tar-ustar subdir-objects]) +AM_INIT_AUTOMAKE([-Wno-portability -Wno-obsolete tar-pax no-dist-gzip dist-xz subdir-objects]) dnl older automake's default of ARFLAGS=cru is noisy on newer binutils; dnl we don't really need the 'u' even in older toolchains. Then there is dnl older libtool, which spelled it AR_FLAGS diff --git a/docs/compiling.html.in b/docs/compiling.html.in index aff5487..d2a3f15 100644 --- a/docs/compiling.html.in +++ b/docs/compiling.html.in @@ -13,7 +13,7 @@ </p>
<pre> - $ gunzip -c libvirt-x.x.x.tar.gz | tar xvf - + $ xz -c libvirt-x.x.x.tar.xz | tar xvf - $ cd libvirt-x.x.x $ ./configure</pre>
diff --git a/docs/downloads.html.in b/docs/downloads.html.in index f213b29..1a3400a 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -28,8 +28,8 @@ </p>
<ul> - <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz">libvirt.org FTP server</a></li> - <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.gz">libvirt.org HTTP server</a></li> + <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.xz">libvirt.org FTP server</a></li> + <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.xz">libvirt.org HTTP server</a></li> </ul>
<h2><a name="schedule">Primary release schedule</a></h2> diff --git a/libvirt.spec.in b/libvirt.spec.in index ee6162e..6b3e888 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -225,7 +225,7 @@ URL: http://libvirt.org/ %if %(echo %{version} | grep -o \\. | wc -l) == 3 %define mainturl stable_updates/ %endif -Source: http://libvirt.org/sources/%{?mainturl}libvirt-%{version}.tar.gz +Source: http://libvirt.org/sources/%{?mainturl}libvirt-%{version}.tar.xz
Requires: libvirt-daemon = %{version}-%{release} Requires: libvirt-daemon-config-network = %{version}-%{release} diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index 6f95832..e808839 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -30,7 +30,7 @@ Summary: MinGW Windows libvirt virtualization library License: LGPLv2+ Group: Development/Libraries URL: http://libvirt.org/ -Source0: ftp://libvirt.org/libvirt/libvirt-%{version}.tar.gz +Source0: ftp://libvirt.org/libvirt/libvirt-%{version}.tar.xz
BuildRequires: mingw32-filesystem >= 95 BuildRequires: mingw64-filesystem >= 95
On Wed, 2016-06-15 at 10:31 -0400, Laine Stump wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. --- I just want to point out that the tarfile is built every time you run "make rpm" (which I do quite a lot - I prefer installing rpms to the carnage created by make install), and this increases the time for make rpm on my system by 1min38sec. (jtomko may have something to say about
On 06/15/2016 09:03 AM, Andrea Bolognani wrote: that, since he's been interested in shaving fractions of a second off the build time in the last few days :-O) Am I going to need to carry a local patch to revert this so that I don't get *even more* bored waiting for builds to complete? Or is there a reasonable way to make it easily configurable with a switch to autogen? (even then I would still need a patch to the specfile, unless we could make it happen based on some environment setting). (Aside from that, I applied the patch and it does work).
This might just be the perfect chance for you to start running libvirtd from the build directory instead - that way, you can save both the time needed to make dist and the time needed to install the new rpm! :) In all seriousness though, this is a reasonable concern, thanks for bringing it up. I don't have any bright ideas on how to make this configurable, short of pre-processing configure.ac and libvirt.spec.in[1] in autogen.sh. Hopefully someone else on the list will come up with a better plan - it would be a shame not to take advantage of xz compression. [1] Which would make them configure.ac.in and... libvirt.spec.in.in, I guess? -- Andrea Bolognani Software Engineer - Virtualization Team
On Wed, Jun 15, 2016 at 05:15:10PM +0200, Andrea Bolognani wrote:
On Wed, 2016-06-15 at 10:31 -0400, Laine Stump wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. --- I just want to point out that the tarfile is built every time you run "make rpm" (which I do quite a lot - I prefer installing rpms to the carnage created by make install), and this increases the time for make rpm on my system by 1min38sec. (jtomko may have something to say about
On 06/15/2016 09:03 AM, Andrea Bolognani wrote: that, since he's been interested in shaving fractions of a second off the build time in the last few days :-O) Am I going to need to carry a local patch to revert this so that I don't get *even more* bored waiting for builds to complete? Or is there a reasonable way to make it easily configurable with a switch to autogen? (even then I would still need a patch to the specfile, unless we could make it happen based on some environment setting). (Aside from that, I applied the patch and it does work).
This might just be the perfect chance for you to start running libvirtd from the build directory instead - that way, you can save both the time needed to make dist and the time needed to install the new rpm! :)
In all seriousness though, this is a reasonable concern, thanks for bringing it up. I don't have any bright ideas on how to make this configurable, short of pre-processing configure.ac and libvirt.spec.in[1] in autogen.sh. Hopefully someone else on the list will come up with a better plan - it would be a shame not to take advantage of xz compression.
Honestly, I think developers should not be using make rpm / make install for their day to day development - the only time you should need to use 'make rpm' is if you actually explicitly want to verify RPM packaging. We've gone to the trouble of making it possible to directly run libvirt from the build directory for all developer use cases. If there's something important that doesn't work when run from the build dir we should fix it. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, Jun 15, 2016 at 10:31:16AM -0400, Laine Stump wrote:
On 06/15/2016 09:03 AM, Andrea Bolognani wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. ---
I just want to point out that the tarfile is built every time you run "make rpm" (which I do quite a lot - I prefer installing rpms to the carnage created by make install), and this increases the time for make rpm on my system by 1min38sec. (jtomko may have something to say about that, since he's been interested in shaving fractions of a second off the build time in the last few days :-O)
Am I going to need to carry a local patch to revert this so that I don't get *even more* bored waiting for builds to complete? Or is there a reasonable way to make it easily configurable with a switch to autogen? (even then I would still need a patch to the specfile, unless we could make it happen based on some environment setting).
You really shouldn't waste your time doing make rpm all the time IMHO. ./autogen.sh --system make -j 12 sudo systemctl stop libvirtd.service sudo ./daemon/libvirtd will "just work(tm)" - its how I've done all libvirt development for years. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 06/15/2016 11:22 AM, Daniel P. Berrange wrote:
On Wed, Jun 15, 2016 at 10:31:16AM -0400, Laine Stump wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. --- I just want to point out that the tarfile is built every time you run "make rpm" (which I do quite a lot - I prefer installing rpms to the carnage created by make install), and this increases the time for make rpm on my system by 1min38sec. (jtomko may have something to say about that, since he's been interested in shaving fractions of a second off the build time in
On 06/15/2016 09:03 AM, Andrea Bolognani wrote: the last few days :-O)
Am I going to need to carry a local patch to revert this so that I don't get *even more* bored waiting for builds to complete? Or is there a reasonable way to make it easily configurable with a switch to autogen? (even then I would still need a patch to the specfile, unless we could make it happen based on some environment setting). You really shouldn't waste your time doing make rpm all the time IMHO.
./autogen.sh --system make -j 12 sudo systemctl stop libvirtd.service sudo ./daemon/libvirtd
will "just work(tm)" - its how I've done all libvirt development for years.
Yeah, I used to do it that way, and at some point I switched to just making the rpm and installing it. I don't even remember now why I did that - it could have just been because I was testing on a different machine from where I was building, or maybe I was rebooting a lot and wanted my new libvirtd to be the one that came up at boot time. At the time I switched, the penalty was small enough that it just became automatic, but over the last year or so the build time (for make -j$LOTS rpm) has slowly crept up to the point where it's now time to retrain my muscle memory and use the in-tree libvirtd. I suppose one downside of that is that make rpm failures won't be noticed as quickly :-)
On Wed, 2016-06-15 at 11:50 -0400, Laine Stump wrote:
You really shouldn't waste your time doing make rpm all the time IMHO.
./autogen.sh --system make -j 12 sudo systemctl stop libvirtd.service sudo ./daemon/libvirtd
will "just work(tm)" - its how I've done all libvirt development for years.
Yeah, I used to do it that way, and at some point I switched to just making the rpm and installing it. I don't even remember now why I did that - it could have just been because I was testing on a different machine from where I was building, or maybe I was rebooting a lot and wanted my new libvirtd to be the one that came up at boot time. At the time I switched, the penalty was small enough that it just became automatic, but over the last year or so the build time (for make -j$LOTS rpm) has slowly crept up to the point where it's now time to retrain my muscle memory and use the in-tree libvirtd.
I suppose one downside of that is that make rpm failures won't be noticed as quickly :-)
https://ci.centos.org/view/libvirt-project/job/libvirt-daemon-rpm/ :) By the way, it's failing right now, but should start to pass again with this patch. I've just pushed it. -- Andrea Bolognani Software Engineer - Virtualization Team
On Wed, Jun 15, 2016 at 10:31:16AM -0400, Laine Stump wrote:
On 06/15/2016 09:03 AM, Andrea Bolognani wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. ---
I just want to point out that the tarfile is built every time you run "make rpm" (which I do quite a lot - I prefer installing rpms to the carnage created by make install), and this increases the time for make rpm on my system by 1min38sec. (jtomko may have something to say about that, since he's been interested in shaving fractions of a second off the build time in the last few days :-O)
Use: XZ_OPT="-3 --threads=0" make rpm The most important speedup comes from dropping the '-e' option which automake uses by default. (-1 is faster than -0 in my testing, -2 and -3 take a few seconds more but drop megabytes off the size. All of them are faster and result in a smaller size than gz --best we used before) On my RHEL, rpmbuild does not recompress sources by default, so this will leave you with a larger srpm. For binary data, the default level is 2: %_binary_payload w2.xzdio but even then the *rpms made with lower compression leves were marginally larger than the default ones. I did not find out why. Jan
On Wed, Jun 15, 2016 at 03:03:19PM +0200, Andrea Bolognani wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. --- Changes from [v1]:
* Update all references to .tar.gz, including spec files, scripts and documentation (thanks Dan) * Fix typo lenght -> length (thanks Ján)
[v1] https://www.redhat.com/archives/libvir-list/2016-June/msg00974.html
ACK Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Wed, 2016-06-15 at 15:03 +0200, Andrea Bolognani wrote:
diff --git a/docs/downloads.html.in b/docs/downloads.html.in index f213b29..1a3400a 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -28,8 +28,8 @@ </p> <ul> - <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz">libvirt.org FTP server</a></li> - <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.gz">libvirt.org HTTP server</a></li> + <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.xz">libvirt.org FTP server</a></li> + <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.xz">libvirt.org HTTP server</a></li> </ul>
It doesn't seem like the hourly snapshots are being generated properly after the switch to xz compression. I guess some server-side script will need to be tweaked. Can someone please look into it? -- Andrea Bolognani Software Engineer - Virtualization Team
On Thu, Jun 16, 2016 at 04:03:01PM +0200, Andrea Bolognani wrote:
On Wed, 2016-06-15 at 15:03 +0200, Andrea Bolognani wrote:
diff --git a/docs/downloads.html.in b/docs/downloads.html.in index f213b29..1a3400a 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -28,8 +28,8 @@ </p> <ul> - <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz">libvirt.org FTP server</a></li> - <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.gz">libvirt.org HTTP server</a></li> + <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.xz">libvirt.org FTP server</a></li> + <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.xz">libvirt.org HTTP server</a></li> </ul>
It doesn't seem like the hourly snapshots are being generated properly after the switch to xz compression. I guess some server-side script will need to be tweaked.
It is done by a crontab in DV's account on libvirt.org. Since I have sudo, I took the liberty to tweak the script to look for tar.xz instead of tar.gz So should be back to normal in an hour or so Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, 2016-06-16 at 15:10 +0100, Daniel P. Berrange wrote:
diff --git a/docs/downloads.html.in b/docs/downloads.html.in index f213b29..1a3400a 100644 --- a/docs/downloads.html.in +++ b/docs/downloads.html.in @@ -28,8 +28,8 @@ </p> <ul> - <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.gz">libvirt.org FTP server</a></li> - <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.gz">libvirt.org HTTP server</a></li> + <li><a href="ftp://libvirt.org/libvirt/libvirt-git-snapshot.tar.xz">libvirt.org FTP server</a></li> + <li><a href="http://libvirt.org/sources/libvirt-git-snapshot.tar.xz">libvirt.org HTTP server</a></li> </ul>
It doesn't seem like the hourly snapshots are being generated properly after the switch to xz compression. I guess some server-side script will need to be tweaked.
It is done by a crontab in DV's account on libvirt.org. Since I have sudo, I took the liberty to tweak the script to look for tar.xz instead of tar.gz So should be back to normal in an hour or so
Awesome, thanks! :) -- Andrea Bolognani Software Engineer - Virtualization Team
participants (4)
-
Andrea Bolognani -
Daniel P. Berrange -
Ján Tomko -
Laine Stump