[Bug 530205] Review Request: AntTweakBar - GUI library for videogame property editing UIs

bugzilla at redhat.com bugzilla at redhat.com
Fri Oct 23 10:12:18 UTC 2009


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=530205


Thomas Spura <tomspur at fedoraproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|nobody at fedoraproject.org    |tomspur at fedoraproject.org
               Flag|                            |fedora-review?




--- Comment #4 from Thomas Spura <tomspur at fedoraproject.org>  2009-10-23 06:12:16 EDT ---
(In reply to comment #3)
> I don't believe the patch will break the Windows build, actually.  I'm rather
> surprised that it builds in MSVC and not GCC by default, given my own
> experience with both compilers; usually it's GCC that pollutes the C++
> namespace when you pull in random headers due to its reliance on C headers for
> implementing libstdc++ and MSVC that requires strict and proper C++ header
> inclusion.  Go figure.  :)

Hmm, let me think about it… No I won't buy MSVC to try it ;)
I just wanted to make your patch only work for linux, as I don't know, what do
to on windows and it builded without it.

Package Review
==============

Key:
 - = N/A
 x = Check
 ! = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [x] Package is named according to the Package Naming Guidelines.
 [x] Spec file name must match the base package %{name}, in the format
%{name}.spec.
 [x] Package meets the Packaging Guidelines
 [x] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested on: 
       [] devel/i386 
       [] devel/x86_64
       [] F11/i386 
       [x] F11/x86_64
 [x] Rpmlint output:
     $ rpmlint AntTweakBar.spec AntTweakBar-1.13-3.fc11.src.rpm
x86_64/AntTweakBar-*
4 packages and 1 specfiles checked; 0 errors, 0 warnings.

 [x] Buildroot is correct
     (%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n))

//////////

 [?] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.

The license file says: "If you use this software in a product, an
acknowledgment in the product documentation would be appreciated." and in the
official zlib says at the end "appreciated but is not required.", but this
should be the same…

//////////

 [x] License field in the package spec file matches the actual license.
     License type: zlib
 [x] 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 is included in %doc.
 [x] Spec file is legible and written in American English.
 [x] Sources used to build the package matches the upstream source, as provided
in the spec URL.
     Upstream source: 2c02dd71d0f86c62f022eed7e0bcb5b8
     Build source:    2c02dd71d0f86c62f022eed7e0bcb5b8
 [x] Package is not known to require ExcludeArch
 [x] All build dependencies are listed in BuildRequires, except for any that
are listed in the exceptions section of Packaging Guidelines.
 [-] The spec file handles locales properly.
 [x] ldconfig called in %post and %postun if required.
 [x] Package must own all directories that it creates.
 [-] Package requires other packages for directories it uses.
 [x] Package does not contain duplicates in %files.
 [x] Permissions on files are set properly.
 [x] Package has a %clean section, which contains rm -rf %{buildroot}.
 [x] Package consistently uses macros.

In the Source0 link is not a macro for the source version, when you sent the
patches upstream, you could ask for a rename to 1.13 so %{version} will match
this at the next release… Or use %global major 1 %global minor 13 as macros.


 [x] Large documentation files are in a -doc subpackage, if required.
 [x] Package uses nothing in %doc for runtime.
 [x] Header files in -devel subpackage, if present.
 [-] Static libraries in -devel subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [x] Development .so files in -devel subpackage, if present.
 [x] Fully versioned dependency in subpackages, if present.
 [x] Package does not contain any libtool archives (.la).
 [-] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [x] Package does not own files or directories owned by other packages.

=== SUGGESTED ITEMS ===
 [x] Latest version is packaged.
 [x] Package does not include license text files separate from upstream.
 [-] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
 [x] Reviewer should test that the package builds in mock.

 [x] Package functions as described (no hardware to test with).
     TwSimpleSDL works great.
 [x] Scriptlets must be sane, if used.
 [-] The placement of pkgconfig(.pc) files is correct.



Three simple issue:
-
https://fedoraproject.org/wiki/Packaging/Guidelines#.25global_preferred_over_.25define

- Patches have no comments, if they are already send upstream. Do so if they
are.

- Should there bee more Requires depencies at runtime for the examples to work?
I believe, if you *always* use SDL and *never* GLUT it can be pretty anoying to
always need to install GLUT anyway. On the other side, without GLUT you can't
compile some examples…
What's your opinion towards this?


_________________

I'd approve this now, but want to get a last answer/opionion to the last issue…
;)

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.




More information about the Fedora-package-review mailing list