Bug 167943

What is the next step in the process?

No one has reviewed this yet... but here is some information to help you out:

If you're a new contributor (if this is your first package) you need to follow
the steps listed here:
http://fedoraproject.org/wiki/Extras/Contributors

I took a very quick glance at your spec file, and the following issues need to
be corrected:

- Use the Fedora standard BuildRoot as defined in PackagingGuidelines
- Don't do this: Release: 1%{?tog_pegasus:.tog_pegasus} You shouldn't be putting
random text in the release field, conditionalized or not. The only thing that
can go there are specific pre/post release cases (e.g. openssl 0.9.6a, mozilla
1.8beta1) or the dist tag (%{?dist}). All of these are documented in
PackagingGuidelines
- Source0: http://prdownloads. ... thats not a valid url (wget will choke on
it). Change it to http://download.sourceforge.net/...
- Unconditionalize your requires. You either need em or you don't. When in
doubt, default to including them and making the package as fully featured as
possible. Same goes for the %configure conditionalizing.
- The devel and test packages need Requires: %{name} = %{version}-%{release},
not just %{version}.
- %setup -n %{name}-%{version} is the default, you can just say %setup
- don't conditionalize the removal of $RPM_BUILD_ROOT, just nuke it. We're
always setting it in the spec file, so we know it will never ever ever be /
without checking.
- don't strip the libraries, the rpm build process does this for us, and saves
it in the -debuginfo package, so we can use those symbols for debugging later.
- you don't need to conditionalize the %postun ldconfig call, because it never
hurts to run ldconfig. :) Also, in the unlikely case that the new package
doesn't install but the old one goes out, we still want the system state to
reflect that.
- Don't use %{version}-%{release} in changelog, this will only be right once.
Hardcode it.

If you have any questions, let me know. Post a package that has the above items
resolved, and I'll do a formal review. :)

Here are some comments from the SBLIM owner:

OK, I have incorporate the changes in a preview package. The new spec file can 
be found at http://prdownloads.sourceforge.net/sblim/sblim-cmpi-base.spec?
download and the SRC RPM is http://prdownloads.sourceforge.net/sblim/sblim-
cmpi-base-1.5.4-1.src.rpm?download .

Perhaps a few words about the context. This package (and others from the SBLIM 
project) is meant to be a plugin for tog-pegasus (or other WBEM servers). 
Therefore it has some "non-standard" characteristics: it uses the same Group 
as tog-pegasus does (Systems Management/Base). Then it ships a few shared 
libraries ending in .so (the ones going to /usr/lib/Pegasus). These are 
provider modules for Pegasus (which is only looking for libs ending in .so, 
not .so.<some-numbers>). Therefore these do not belong to the devel package. 
The other shared objects (in /usr/lib) do follow the usual conventions.

Thanks!

Hello.  Would someone mind performing a formal review, please?

I have now completed review of theses sblim packages, and have verified that
all tests pass with tog-pegasus-2.5-4+ :
  sblim-cmpi-base-1.5.4-3+
  sblim-wbemcli-1.5.1-1+
  sblim-testsuite-1.2.4-1+
All the tests in sblim-testsuite-1.2.4-1+ pass with these packages installed.

These packages seem fine to go into FC Extras .

Mark, do have a sponsor already? Is this the only packager currently under
review for extras?

Hi Thorsten,

I do not think so.  Perhaps Jason might be??  I have been working with him in 
the past for these packages.

I am starting with the sblim-cmpi-base, sblim-testsuite, and sblim-wbemcli.  
If those are accepted, then I will be added more later.

The spec files and source RPMS are located under 
http://sourceforge.net/project/showfiles.php?group_id=128809
for the respective packages.

So, how do I find a sponsor now?

What is the next step in this process?

in reply to comment #8:

It looks like spot in comment #2 indicated he would do a formal review, and
perhaps he is going to sponsor you as well. 

Next step is to wait for that, but while you are waiting you can comment on
other packages that are in review to show any potential sponsors that you
understand the package guidelines well. 

You can find such a list at: 
https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=FE-REVIEW&hide_resolved=1

OK, I've now completed review, and sponsored Mark Hamzy to submit the packages .

Properly block FE-ACCEPT

New Package CVS Request
=======================
Package Name: sblim-cmpi-base
Short Description: Standards Based Linux Instrumentation Base CMPI Providers
Owners: praveenp hamzy srini
Branches: EL-4 EL-5
InitialCC: praveenp

You do not own that package in Fedora, and I see no indication that the existing Fedora owner wishes to have their packages branched for EPEL.  Please see https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL, get an ack from the current owner of the Fedora package, adjust the Owners: field if necessary and re-set the CVS flag.

I am fine with EPEL

You're not the current package owner in Fedora as far as I can tell.  Nor are you the co-maintainer, nor are you even CC'd on commits.

https://admin.fedoraproject.org/pkgdb/packages/name/sblim-cmpi-base

Package Change Request
======================
Package Name: sblim-cmpi-base
New Branches: EL-4 EL-5
Owners: vcrhonek

cvs done.

Thanks!