Spec URL: http://www.pixelbeat.org/patches/oz.spec SRPM URL: http://www.pixelbeat.org/patches/oz-0.4.0-2.fc15.src.rpm Hi, oz is part of http://aeolusproject.org/ and we'd like to make it available in Fedora. One question I had was, perhaps it would be better named as aeolus-oz to make it immediately obvious to what function it belongs?
oz seems to make sense from a project name perspective. Maybe Chris has a different viewpoint. I will provide review of this package.
MUST review: MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[1] FAIL: there are a few problems in the rpmlint results. This is a BLOCKER. the source rpm [sdake@beast Downloads]$ rpmlint oz*src.rpm oz.src: W: non-standard-group Development oz.src: W: invalid-url Source0: oz-0.4.0.tar.gz 1 packages and 0 specfiles checked; 0 errors, 2 warnings. the rpm: [sdake@beast noarch]$ rpmlint oz* oz.noarch: W: non-standard-group Development oz.noarch: E: non-executable-script /usr/lib/python2.7/site-packages/oz/guesttools/icicle-nc 0644L /bin/bash 1 packages and 0 specfiles checked; 1 errors, 1 warnings. 1. Source0 should be a full url. I recommend: I recommend: Source0: http://repos.fedorahosted.org/repos/aeolus/oz/0.4.0/tarball/%{name}-%{version}.tar.gz 2. Group should either be "Development Tools" or "Development Libraries". 3. icicle-nc should have its permissions set to 755. MUST: The package must be named according to the Package Naming Guidelines . PASS: the package is named according to package naming guidelines. MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [2] . PASS: The spec file name matches the base package name. MUST: The package must meet the Packaging Guidelines . PASS: package meets packaging guidelines. MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . PASS: The package is licensed under lgplv2.1 which is an approved license. MUST: The License field in the package spec file must match the actual license. [3] FAIL: The COPYING file and header files indicate the code is licensed under lgplv2.1, however, spec file indicates code licensed under lgplv2 MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.[4] PASS: package contains a license file and that license file in %do section MUST: The spec file must be written in American English. [5] PASS: spec file written in English MUST: The spec file for the package MUST be legible. [6] PASS: spec file is very legible MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. The source0 package should be the upstream package location including url. upstream package: from SRC RPM: FAIL - md5sums do not match this is a BLOCKER [sdake@beast Downloads]$ md5sum oz-0.4.0.tar.gz cd1639af62509c677c95d94705042772 oz-0.4.0.tar.gz md5sum [sdake@beast SOURCES]$ md5sum oz-0.4.0.tar.gz d2f774e97ca5ac0c34b9f07b6ea1bd01 oz-0.4.0.tar.gz MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. [7] PASS - I personally built on x86_64 MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. [8] PASS - this is a noarch python package MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. PASS - I built on clean cloned f15 VM that are expected in the build root. I then installed python (build requires) and package builds properly. MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9] PASS - no locale functionality is included upstream. MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [10] PASS - this package is python only (noarch) and does not have shared objects MUST: Packages must NOT bundle copies of system libraries.[11] PASS - no system libraries are bundled by package. MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [12] PASS - no request for relocate functionality. MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [13] PASS - all directories needed by package are owned by package or created by depends. MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)[14] PASS - all files only listed once in a spec file MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. [15] FAIL - icicle-nc is not set with execute permissions - THIS IS A BLOCKER MUST: Each package must consistently use macros. [16] PASS - all macros used consistently MUST: The package must contain code, or permissable content. [17] PASS - the package contains python code, man pages, and installation scripts. All content is permissible per 17. MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [18] PASS - there are only a few man pages, and the reviewer doesn't recommend a -doc package. MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [18] PASS - doc's are "%doc README COPYING" not effecting runtime if not present MUST: Header files must be in a -devel package. [19] PASS - no header files MUST: Static libraries must be in a -static package. [20] PASS - no static libraries MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [19] PASS - no shared objects MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release} [21] PASS - no devel package MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[20] PASS - no libtool files MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [22] PASS - there is no desktop GUI MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [23] PASS - the package owns the following directories: %dir %attr(0755, root, root) %{_sysconfdir}/oz/ %dir %attr(0755, root, root) %{python_sitelib}/oz %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/ %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/isocontent/ %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/isos/ %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/mnt/ %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/floppycontent/ %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/floppies/ %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/icicletmp/ %dir %attr(0755, root, root) %{_localstatedir}/lib/oz/jeos these are all application specific. MUST: All filenames in rpm packages must be valid UTF-8. [24] PASS - all filenames are UTF-8 encoded
Summary of MUST review blockers: MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[1] FAIL: there are a few problems in the rpmlint results. This is a BLOCKER. the source rpm [sdake@beast Downloads]$ rpmlint oz*src.rpm oz.src: W: non-standard-group Development oz.src: W: invalid-url Source0: oz-0.4.0.tar.gz 1 packages and 0 specfiles checked; 0 errors, 2 warnings. the rpm: [sdake@beast noarch]$ rpmlint oz* oz.noarch: W: non-standard-group Development oz.noarch: E: non-executable-script /usr/lib/python2.7/site-packages/oz/guesttools/icicle-nc 0644L /bin/bash 1 packages and 0 specfiles checked; 1 errors, 1 warnings. 1. Source0 should be a full url. I recommend: I recommend: Source0: http://repos.fedorahosted.org/repos/aeolus/oz/0.4.0/tarball/%{name}-%{version}.tar.gz 2. Group should either be "Development Tools" or "Development Libraries". 3. icicle-nc should have its permissions set to 755.MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[1] FAIL: there are a few problems in the rpmlint results. This is a BLOCKER. the source rpm [sdake@beast Downloads]$ rpmlint oz*src.rpm oz.src: W: non-standard-group Development oz.src: W: invalid-url Source0: oz-0.4.0.tar.gz 1 packages and 0 specfiles checked; 0 errors, 2 warnings. the rpm: [sdake@beast noarch]$ rpmlint oz* oz.noarch: W: non-standard-group Development oz.noarch: E: non-executable-script /usr/lib/python2.7/site-packages/oz/guesttools/icicle-nc 0644L /bin/bash 1 packages and 0 specfiles checked; 1 errors, 1 warnings. 1. Source0 should be a full url. I recommend: I recommend: Source0: http://repos.fedorahosted.org/repos/aeolus/oz/0.4.0/tarball/%{name}-%{version}.tar.gz 2. Group should either be "Development Tools" or "Development Libraries". 3. icicle-nc should have its permissions set to 755. MUST: The License field in the package spec file must match the actual license. [3] FAIL: The COPYING file and header files indicate the code is licensed under lgplv2.1, however, spec file indicates code licensed under lgplv2 MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. The source0 package should be the upstream package location including url. upstream package: from SRC RPM: FAIL - md5sums do not match this is a BLOCKER [sdake@beast Downloads]$ md5sum oz-0.4.0.tar.gz cd1639af62509c677c95d94705042772 oz-0.4.0.tar.gz md5sum [sdake@beast SOURCES]$ md5sum oz-0.4.0.tar.gz d2f774e97ca5ac0c34b9f07b6ea1bd01 oz-0.4.0.tar.gz MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. [15] FAIL - icicle-nc is not set with execute permissions - THIS IS A BLOCKER
Pádraig, Please resolve the failing MUST review items in comment #3. The differing md5sums are particularly troubling. If you have made changes to the source tree, I'd recommend requesting upstream to release a new tarball. Further review is blocked until MUST items are resolved. Regards -steve
(In reply to comment #1) > oz seems to make sense from a project name perspective. Maybe Chris has a > different viewpoint. I will provide review of this package. Yeah, I would go with oz as the package name. Although this is part of the aeolus project, my feeling is that oz has use outside of the project. Pádraig, once you fix the issues that Steve found, I would appreciate patches to the .spec file upstream. At least then we can keep it mostly in-sync with what is in Fedora. Thanks, Chris Lalancette
The md5sum discrepancies are because there is no usable (noarch) upstream tarball yet. I wanted to clarify things before asking chris to release (0.4.1). Note I'll be using ...fedorapeople... rather than ...fedorahosted... for the URL, as the latter doesn't seem to exist at the moment. Patch to aeolus-devel coming up... thanks!
(In reply to comment #6) > The md5sum discrepancies are because there is no usable (noarch) upstream > tarball yet. I wanted to clarify things before asking chris to release (0.4.1). > > Note I'll be using ...fedorapeople... rather than ...fedorahosted... for the > URL, as the latter doesn't seem to exist at the moment. > > Patch to aeolus-devel coming up... > > thanks! Hm. I might suggest that you just use the 0.4.0 release directly (i.e. the arch-specific one). Yes, it sucks a bit that it is arch-specific, but when I release 0.5.0, we can then upgrade to that and move it to noarch[1]. Another option is to use the 0.4.0 release tarball, but put the noarch patch in as a specfile patch on top of that. It makes me a bit nervous, though; that is a big change, and I haven't yet run that patch through my full functional tests. Chris Lalancette [1] Given the number of fixes that are coming into oz lately, it looks like I'll probably do a 0.5.0 bugfix release sooner rather than later. So it may not be all that long.
yup fedorapeople is the current url that comes up with you click download. mistype on my part. thanks for catching ! In reply to comment #6, an RPM source tarball must be pristine matching exactly what upstream releases. Many automated tools use the upstream source tarball for their internal consistency and security checks. Patches on top of that that are distro specific but not merged upstream are allowed (but highly discouraged and usually limited in scope to things like init scripts etc). Patches on top of a source tarball as separate patch# lines that are merged into the declared upstream repo are fine (this was chris's second option).
Yes I understand the tarball must be public and unchanging. The process I use personally for one project is: http://www.pixelbeat.org/docs/linux_project_release_process/ So I've sent the rpmlint fixes upstream. Assuming they're merged the next step is to wait for the oz-0.5.0.tar.gz If there is a particular need to release an oz package to fedora in the meantime, I'll patch against oz-0.4.0.tar.gz thanks!
(In reply to comment #9) > Yes I understand the tarball must be public and unchanging. > The process I use personally for one project is: > http://www.pixelbeat.org/docs/linux_project_release_process/ > > So I've sent the rpmlint fixes upstream. > Assuming they're merged the next step is to wait for the oz-0.5.0.tar.gz > > If there is a particular need to release an oz package to fedora in the > meantime, > I'll patch against oz-0.4.0.tar.gz > > thanks! Hey Pádraig, Steve, I did the 0.5.0 release of Oz today, with the noarch patches. So we should be good to package that up as a noarch for Fedora-16. Thanks, Chris Lalancette
Yup, When Pádraig submits a new rpm I'll review. Regards -steve
Updated srpm for review: Spec URL: http://www.pixelbeat.org/patches/oz.spec SRPM URL: http://www.pixelbeat.org/patches/oz-0.5.0-1.fc15.src.rpm
(new) fedora guidelines say: + BuildRoot is unnecessary, just get rid of it + %defattr, ditto + %clean, ditto [ OK ] MUST: rpmlint must be run on every package [ OK ] MUST: The package must be named according to the Package Naming Guidelines [ OK ] MUST: The spec file name must match the base package %{name} [...] [ OK ] MUST: The package must meet the Packaging Guidelines [ OK ] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines [ FAIL ] MUST: The License field in the package spec file must match the actual license spec still says LGPL2, COPYING says LGPL2.1 [ OK ] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc [ OK ] MUST: The spec file must be written in American English. [ OK ] MUST: The spec file for the package MUST be legible. [ ] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. [ OK ] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture [ N/A ] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line [ OK ] MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. [ N/A ] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden [ N/A ] MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [ N/A ] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [ OK ] MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [ OK ] MUST: A package must not contain any duplicate files in the %files listing. [ OK ] MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. [ OK ] MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [ FAIL ] MUST: Each package must consistently use macros. - clalance: minor, but Source0 can be changed to use %{name}-%{version}. [ OK ] MUST: The package must contain code, or permissable content. [ OK ] MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [ OK ] MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [ N/A ] MUST: Header files must be in a -devel package. [ N/A ] MUST: Static libraries must be in a -static package. [ N/A ] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). [ N/A ] MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. [ N/A ] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} [ N/A ] MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. [ N/A ] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [ OK ] MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [ OK ] MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [ OK ] MUST: All filenames in rpm packages must be valid UTF-8. [ ] SHOULD query upstream to include it. [ N/A ] SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. [ ] SHOULD: The reviewer should test that the package builds in mock. - [ ] SHOULD: The package should compile and build into binary rpms on all supported architectures [ ] SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. [ ] SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. [ N/A ] SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. [ N/A ] SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. [ N/A ] SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. [ N/A ] SHOULD: your package should contain man pages for binaries/scripts. If it doesn't, work with upstream to add them where they make sense.[34]
Updated srpm for review: Spec URL: http://www.pixelbeat.org/patches/oz.spec SRPM URL: http://www.pixelbeat.org/patches/oz-0.5.0-2.fc15.src.rpm (In reply to comment #13) > (new) fedora guidelines say: > + BuildRoot is unnecessary, just get rid of it > + %defattr, ditto > + %clean, ditto Done > [ FAIL ] MUST: The License field in the package spec file must match the > actual license > > spec still says LGPL2, COPYING says LGPL2.1 I responded to this previously. It seems that these 2 are synonymous. If I use 2.1 in the spec, rpmlint will complain. See: http://www.redhat.com/a-packaging/2008-November/msg00047.html and: http://fedoraproject.org/wiki/Licensing (if you search for "LGPLv2" there, you see that it covers both LGPLv2 and LGPLv2.1) > [ OK ] MUST: Each package must have a %clean section, which contains rm -rf > %{buildroot} (or $RPM_BUILD_ROOT). Note that conflicts with the request to remove %clean (which I've done) > [ FAIL ] MUST: Each package must consistently use macros. - clalance: minor, > but Source0 can be changed to use %{name}-%{version}. %{name}/%{version} now used. thanks!
>> [ OK ] MUST: Each package must have a %clean section, which contains rm -rf >> %{buildroot} (or $RPM_BUILD_ROOT). > >Note that conflicts with the request to remove %clean (which I've done) My bad, I missed that and did not remove it. Ignore it.
I'll validate the remaining SHOULDs by EOD today. [ ] SHOULD: The reviewer should test that the package builds in mock. - [ ] SHOULD: The package should compile and build into binary rpms on all supported architectures [ ] SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. [ ] SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. thanks for the re-review Kaleb of the new upstream release.
[ PASS ] SHOULD: The reviewer should test that the package builds in mock. - http://koji.fedoraproject.org/koji/taskinfo?taskID=3182672 [ PASS ] SHOULD: The package should compile and build into binary rpms on all supported architectures [ PASS ] SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. I was able to use the koji package and boot different vms using pacemaker-cloud which extensively exercises oz image creation: pcloudsh# deployable_start dep1 Starting Deployable dep1 - Starting Assembly assy1 - Starting Assembly assy2 - Starting Assembly assy3 pcloudsh# Event: {'reason': 'All good', 'assembly': 'assy3', 'state': 'running', 'deployable': 'dep1'} Event: {'reason': 'All good', 'assembly': 'assy1', 'state': 'running', 'deployable': 'dep1'} Event: {'reason': 'All good', 'assembly': 'assy2', 'state': 'running', 'deployable': 'dep1'} Event: {'reason': 'started OK', 'assembly': 'assy3', 'state': 'running', 'service': 'httpd', 'deployable': 'dep1'} Event: {'reason': 'started OK', 'assembly': 'assy3', 'state': 'running', 'service': 'httpd', 'deployable': 'dep1'} Event: {'reason': 'started OK', 'assembly': 'assy1', 'state': 'running', 'service': 'httpd', 'deployable': 'dep1'} Event: {'reason': 'started OK', 'assembly': 'assy2', 'state': 'running', 'service': 'httpd', 'deployable': 'dep1'} [ N/A ] SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity.
Package passes packaging guidelines. Applying fedora-review+. Thanks for packaging and continuing the rest of the submission process. Regards -steve
New Package SCM Request ======================= Package Name: oz Short Description: Library and utilities for automated guest OS installs Owners: pbrady sdake clalance Branches: f14 f15 el5 el6 InitialCC:
Git done (by process-git-requests).
oz-0.5.0-2.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/oz-0.5.0-2.fc15
oz-0.5.0-2.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/oz-0.5.0-2.el6
oz-0.5.0-2.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/oz-0.5.0-2.fc14
oz-0.5.0-2.el6 has been pushed to the Fedora EPEL 6 testing repository.
Padraig, Thanks for the packaging. Would you transfer package owner to clalance? He is ultimately responsible for controlling the commit/acl list since it is his upstream package. Thanks -steve
Chris I've removed myself as owner, so you should be able to take ownership at: https://admin.fedoraproject.org/pkgdb/acls/name/oz
Thanks Pádraig, I've taken ownership.
oz-0.5.0-2.fc15 has been pushed to the Fedora 15 stable repository.
oz-0.5.0-2.fc14 has been pushed to the Fedora 14 stable repository.