[Bug 168635] Review Request: colorscheme: generate a variety of colorschemes from a single starting color

bugzilla at redhat.com bugzilla at redhat.com
Tue Sep 20 04:36:41 UTC 2005


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

Summary: Review Request: colorscheme: generate a variety of colorschemes from a single starting color


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


toshio at tiki-lounge.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|163776                      |163778
              nThis|                            |




------- Additional Comments From toshio at tiki-lounge.com  2005-09-20 00:36 EST -------
APPROVED
But see Notes.

b017737456db88209a405e26b81b6f64  colorscheme.spec
49ee1ae0b442054e1857a27d90591f6e  colorscheme-0.2.1-1.src.rpm

Good:
* Package name follows namng guidelines.
* spec is named after the package name.
* License is GPL, matches the spec name, and is included in the package.
* Spec file is legible
* Builds on x86_64.
* No ExcludeArchs yet.
* No excluded BuildRequires.
* Builds in mock
* Matches upstream source
* Owns all directories
* No duplicate files
* Permissions set correctly
* Has %clean section
* Makes good use of macros
* Code not content
* Properly contains a .desktop file.

Minor:
* rpmlint gives:
  W: colorscheme wrong-file-end-of-line-encoding
/usr/share/doc/colorscheme-0.2.1/TODO
  This could be fixed with dos2unix, ignored, or the TODO file could be left
  out of the distribution.  It isn't terribly useful.

Notes:
* colorscheme has its own unittests.  These are enabled by buildrequiring
  cppunit-devel and running make check in the %check section.  I tried to
  run the tests on the current package and found that quite a few of them
  failed.  If this isn't known, you might want to run the tests and submit
  a bug upstream.
* I don't believe there's a lot of value in including the .sig.  A reviewer
  still has to go to the project website to verify the origin of the .sig and
  (most of the time) that the key seems to belong to the upstream author.
  The .sig should be checked by the reviewer but not included in the finished
  package.  If you have/know of another view, feel free to share.


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




More information about the fedora-extras-list mailing list