Bug 479953

Good:
+ Base name of the SPEC file metches with package name
+ Package name fits with naming guidelines
+ Package contains most recent release.
+ Tar ball could be downloaded from upstream vis spectool
+ Tar Ball in package matches with upstream
(md5sum: 2306402f31dff1cb9d3d664aa9153c28)
+ License tag contains valid OSS license
+ Package contains verbatin text of the license
+ content of the license tag fits with copyright notes in the source files
+ Rpmlint is ok for source rpm
+ Package contains devel subpackage
+ devel subpackage contains req. to main package
+ %doc stanza is small, so we need no extra doc subpackage
+ Files of the package belongs to the package
+ Files doesn't owned by an other package

Bad:
- Local build fails with:
checking for gm4... no
checking for m4... m4
checking whether m4 is GNU m4... no
checking whether make is GNU Make... yes
checking for x86_64-unknown-linux-gnu-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GTKSOURCEVIEWMM... configure: error: Package requirements (gtkmm-2.4 >= 2.4 gtksourceview-2.0 >= 2.2.0) were not met:

No package 'gtksourceview-2.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables GTKSOURCEVIEWMM_CFLAGS
and GTKSOURCEVIEWMM_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

- Build on koji fails, Please refer to http://koji.fedoraproject.org/koji/taskinfo?taskID=1053743
- Group tag should be Development/Libraries

Yikes, fixed thanks!

> Group tag should be Development/Libraries

Hmm, are you certain ? I'm using the same Group (for the libraries) as is used for all other glib/gtk packages, such as glib2, gtk2, gtkmm24, etc...


Spec URL: http://www.poolshark.org/src/gtksourceviewmm.spec
SRPM URL: http://www.poolshark.org/src/gtksourceviewmm-2.2.0-2.fc10.src.rpm

Good:
+ Name of the package fits naming guidelines
+ Version of the tar ball matches with package version
+ Packaged version is the most current release of the application
+ Package contains a valid license tag
+ License tag contains GPLv2+ as an valid OSS license
+ Package contains verbatin copy of the license text
+ Source in package matches with upstream
(md5sum: 2306402f31dff1cb9d3d664aa9153c28)
+ Consistently usage of rpm macros
+ Package contains devel subpackage
+ Devel subpackage containts proper Req. to main package
+ Package contains no patches
+ %setup use -q flag
+ BUILDROOT will cleaned on the beginning of %install and %clean
+ Local build works fine
+ Build use %{_smp_flags]
+ Build use $RPM_OPT_FLAGS
+ Local install works fine
+ Rpmlint has no complaints for installed package
+ Local uninstall works file
+ Koji build works file
+ Package contains dlconfig scriptlets
+ Rpmlint has no complaints for source rpm
+ Rpmlint has no complaints for the binary rpm
+ Rpmlint has no complaints for the debuginfo rpm
+ Debuginfo rpm contains source files
+ Packaged files doesN't belongs to another package
+ Packaged files have proper file permissions
+ %doc stanza is small, so we need no extra doc subpackage
+ %changelog has a proper format

*** APPROVED ***

New Package CVS Request
=======================
Package Name: gtksourceviewmm
Short Description: C++ wrapper for the gtksourceview widget library
Owners: denis
Branches: 
InitialCC:

cvs done.

Jochen, thanks for the review.

UNfortunately, I'M was not aware, that ther is a libgtksourceviewmm package which is depending on gtksourceview. So I wan't to suggest, that you are renaming the package into libgtksourceviewmm2 for clarification, if possible.

I would rather not, since the upstream tarball name was indeed renamed to "gtksourceviewm" for the 2.0 API release. In a way the naming of the 1.0 API to "libgtksourceviewmm" was an anomaly which got corrected :-)

Also, the plan is to EOL libgtksourceviewmm.

Package Change Request
======================
Package Name: gtksourceviewmm
New Branches: el5 el6
Owners: hguemar

I am requesting an EPEL 6 branch for this package because I would like the Nemiver debugger package (which I maintain) to be part of EPEL 6.

I am proposing my help to maintain gtksourceviewmm in the EPEL 6 branch as well and did the request in pkgdb.

The n-v-r that works with EPEL 6 gtksourceviewmm-2.2.0-4 as it is the one that is compatible with the gtksourceview2-2.8.2-4.el6. So that's the gtksourceviewmm of Fedora 12. Newer versions of gtksourceviewmm require greater versions of gtksourceview so they are not suitable for EL6 for now. 

I have built that version of gtksourceviewmm on EL6 (along with the other dependencies of Nemiver) and verified that it works well with the Nemiver package so far, in EL6. The RPMs and SRPMs are available for testing at http://seketeli.net/repos/EL6/x86_64/ and
http://seketeli.net/repos/EL6/SRPMS/

I forgot to say that I maintain the Nemiver debugger package in both upstream and Fedora, FWIW.

Git done (by process-git-requests).