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@xxxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|nobody@xxxxxxxxxxxxxxxxx |tomspur@xxxxxxxxxxxxxxxxx Flag| |fedora-review? --- Comment #4 from Thomas Spura <tomspur@xxxxxxxxxxxxxxxxx> 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. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review