For packages hosted on sourceforge, use 

Source0: http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz

See https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net

Thanks for pointing out. I have rewritten the spec and SRPM files accordingly.

$ rpmlint libwbxml.spec ../SRPMS/libwbxml-0.10.8-1.fc13.src.rpm ../RPMS/x86_64/libwbxml-*
libwbxml.x86_64: W: no-manual-page-for-binary xml2wbxml
libwbxml.x86_64: W: no-manual-page-for-binary wbxml2xml
4 packages and 1 specfiles checked; 0 errors, 2 warnings.

Some suggestions:
1.Provides:       wbxml2 = %{version}-%{release} is not useful since no rpm is actually depends wbxml2 explicitly.

2.
BuildRequires:  cmake, expat-devel, perl

Requires:      libxml2-devel, pkgconfig

rpmbuild will add pkgconfig as a dependency automatically[1], perl is on the exception list of Buildrequires[2](There is no need to include the following packages or their dependencies as BuildRequires).

[1]http://fedoraproject.org/wiki/PackagingGuidelines#Pkgconfig_Files
[2]http://fedoraproject.org/wiki/PackagingGuidelines#Exceptions_2

3.

%build
# Upstream does not support in-source-directory building
SRCDIR="$PWD"
%define builddir ../build
rm -rf %{builddir}
mkdir %{builddir}
cd %{builddir}
%cmake "$SRCDIR"
make %{?_smp_mflags}

->

 %build
 mkdir -p %{_target_platform}
 pushd %{_target_platform}
 %{cmake} ..
 popd

 make %{?_smp_mflags} -C %{_target_platform}

 %install
 rm -rf %{buildroot}
 make install/fast DESTDIR=%{buildroot} -C %{_target_platform}

See http://fedoraproject.org/wiki/SIGs/KDE, this is also suggested as the next version cmake packaging guideline in Fedora.


4.

%files devel
%defattr(-,root,root,-)
%doc AUTHORS BUGS ChangeLog COPYING GNU-LGPL NEWS README References THANKS TODO

You should not try to add duplicate docs to -devel, rpmlint warnings can be safely ignored.

5.

%files
%{_libdir}/libwbxml2.so.0*
->
%{_libdir}/libwbxml2.so.*

If upstream bumps soname, you don't need to modify %files again.

(In reply to comment #3)
> Some suggestions:
> 1.Provides:       wbxml2 = %{version}-%{release} is not useful since no rpm is
> actually depends wbxml2 explicitly.
> 
But it does not breaks anything. More ever think about third-party repositories.

In addition, pure theoretically, there is a direct dependency:

$ repoquery --requires wbxml2-devel | grep wbxml2
libwbxml2.so.0
wbxml2 = 0.9.2-16.fc12
libwbxml2.so.0()(64bit)
wbxml2 = 0.9.2-16.fc12

One could say if wbxml2-devel is installed, wbxml2 is installed too. However who knows how much broken system can an user have.

> 2.
> BuildRequires:  cmake, expat-devel, perl
> 
> Requires:      libxml2-devel, pkgconfig
> 
> rpmbuild will add pkgconfig as a dependency automatically[1],

What about EPEL-5? It's not supported currently, but I'd like to be prepared for future possibilities.

> perl is on the exception list of Buildrequires[2]
> [2]http://fedoraproject.org/wiki/PackagingGuidelines#Exceptions_2
>
It's not listed.
 
> 3.
> 
> %build
> # Upstream does not support in-source-directory building
> SRCDIR="$PWD"
> %define builddir ../build
> rm -rf %{builddir}
> mkdir %{builddir}
> cd %{builddir}
> %cmake "$SRCDIR"
> make %{?_smp_mflags}
> 
> ->
> 
>  %build
>  mkdir -p %{_target_platform}
>  pushd %{_target_platform}
>  %{cmake} ..
>  popd
> 
>  make %{?_smp_mflags} -C %{_target_platform}
> 
Why popd and then make -C if one can do make without -C and then popd?

> 4.
> 
> %files devel
> %defattr(-,root,root,-)
> %doc AUTHORS BUGS ChangeLog COPYING GNU-LGPL NEWS README References THANKS TODO
> 
> You should not try to add duplicate docs to -devel, rpmlint warnings can be
> safely ignored.
>
Ok. I will remove them but COPYING and GNU-LGPL because it's new rule that every package must deliver license copy if some exists in sources.

(In reply to comment #4)
> > Some suggestions:
> > 1.Provides:       wbxml2 = %{version}-%{release} is not useful since no rpm is
> > actually depends wbxml2 explicitly.
> > 
> But it does not breaks anything. More ever think about third-party
> repositories.
> In addition, pure theoretically, there is a direct dependency:
> $ repoquery --requires wbxml2-devel | grep wbxml2
> libwbxml2.so.0
> wbxml2 = 0.9.2-16.fc12
> libwbxml2.so.0()(64bit)
> wbxml2 = 0.9.2-16.fc12
> One could say if wbxml2-devel is installed, wbxml2 is installed too. However
> who knows how much broken system can an user have.
This is not true, rpm should not try to depend on any shlibs explicitly.

See http://fedoraproject.org/wiki/PackageNamingGuidelines#Renaming.2Freplacing_existing_packages
"For packages that are not usually pulled in by using the package name as the dependency such as library only packages (which are pulled in through library soname depenencies), there's usually no need to add the Provides. Note however that the -devel subpackages of lib packages are pulled in as build dependencies using the package name, so adding the Provides is often appropriate there."

> > 2.
> > BuildRequires:  cmake, expat-devel, perl
> > 
> > Requires:      libxml2-devel, pkgconfig
> > 
> > rpmbuild will add pkgconfig as a dependency automatically[1],
> What about EPEL-5? It's not supported currently, but I'd like to be prepared
> for future possibilities.
> > perl is on the exception list of Buildrequires[2]
> > [2]http://fedoraproject.org/wiki/PackagingGuidelines#Exceptions_2
> >
> It's not listed.

wbxml2 is actually provided by some 3rd repos for rhel5, it'll better not to introduce big update in rhel5. perl is a dependency to those exception.

See http://kojipkgs.fedoraproject.org/packages/gzip/1.3.13/4.fc13/data/logs/i686/root.log for a complete exception list.

> > 3.
> > 
> > %build
> > # Upstream does not support in-source-directory building
> > SRCDIR="$PWD"
> > %define builddir ../build
> > rm -rf %{builddir}
> > mkdir %{builddir}
> > cd %{builddir}
> > %cmake "$SRCDIR"
> > make %{?_smp_mflags}
> > 
> > ->
> > 
> >  %build
> >  mkdir -p %{_target_platform}
> >  pushd %{_target_platform}
> >  %{cmake} ..
> >  popd
> > 
> >  make %{?_smp_mflags} -C %{_target_platform}
> > 
> Why popd and then make -C if one can do make without -C and then popd?

Either way is OK, but using ways listed in guideline will keep our spec files more clearly

> > 4.
> > 
> > %files devel
> > %defattr(-,root,root,-)
> > %doc AUTHORS BUGS ChangeLog COPYING GNU-LGPL NEWS README References THANKS TODO
> > 
> > You should not try to add duplicate docs to -devel, rpmlint warnings can be
> > safely ignored.
> >
> Ok. I will remove them but COPYING and GNU-LGPL because it's new rule that
> every package must deliver license copy if some exists in sources.    

This is incorrect, because -devel subpackage already depend on mainpackage(e.g. a package which has -libs and -devel subpackages, then you just need to add license Text to -libs subpackage, mainpackage and -devel subpackage don't need this text).

See http://fedoraproject.org/wiki/Packaging/LicensingGuidelines

Subpackage Licensing 

If a subpackage is dependent (either implicitly or explicitly) upon a base package (where a base package is defined as a resulting binary package from the same source RPM which contains the appropriate license texts as %doc), it is not necessary for that subpackage to also include those license texts as %doc. 

However, if a subpackage is independent of any base package (it does not require it, either implicitly or explicitly), it must include copies of any license texts (as present in the source) which are applicable to the files contained within the subpackage.

Ok. Everything seems reasonable except the perl dependency.

One cannot omit build requires just because they can be interfered from a package of the system build requires list (in this case the perl is pulled because of rpm-build and redhat-rpm-config).

The reason is the concrete base package implementation can change resulting on not pulling perl anymore. (Imagine some crazy man rewrites rpm-build from Perl into Python).

(In reply to comment #6)
> Ok. Everything seems reasonable except the perl dependency.
> 
> One cannot omit build requires just because they can be interfered from a
> package of the system build requires list (in this case the perl is pulled
> because of rpm-build and redhat-rpm-config).
> 
> The reason is the concrete base package implementation can change resulting on
> not pulling perl anymore. (Imagine some crazy man rewrites rpm-build from Perl
> into Python).    

OK, apply those changes and keep perl as a BR, then I'll approve this package.

New spec and SRPM uploaded:

Spec URL: http://ppisar.fedorapeople.org/libwbxml/libwbxml.spec
SRPM URL: http://ppisar.fedorapeople.org/libwbxml/libwbxml-0.10.8-1.fc13.src.rpm

Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2390930

$ rpmlint libwbxml.spec ../SRPMS/libwbxml-0.10.8-1.fc13.src.rpm ../RPMS/x86_64/libwbxml-*
libwbxml-devel.x86_64: W: no-documentation
libwbxml.x86_64: W: obsolete-not-provided wbxml2
libwbxml.x86_64: W: no-manual-page-for-binary xml2wbxml
libwbxml.x86_64: W: no-manual-page-for-binary wbxml2xml
4 packages and 1 specfiles checked; 0 errors, 4 warnings.


Diff to old spec file:

--- libwbxml.spec	2010-08-09 09:59:53.000000000 +0200
+++ /home/petr/rpmbuild/SPECS/libwbxml.spec	2010-08-10 10:47:49.005302937 +0200
@@ -12,7 +12,6 @@
 BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 BuildRequires:  cmake, expat-devel, perl
-Provides:       wbxml2 = %{version}-%{release}
 Obsoletes:      wbxml2 <= 0.9.3
 
 %description
@@ -43,24 +42,21 @@
 
 %build
 # Upstream does not support in-source-directory building
-SRCDIR="$PWD"
-%define builddir ../build
-rm -rf %{builddir}
-mkdir %{builddir}
-cd %{builddir}
-%cmake "$SRCDIR"
-make %{?_smp_mflags}
+mkdir -p %{_target_platform}
+pushd %{_target_platform}
+%cmake ..
+popd
+make -C %{_target_platform} %{?_smp_mflags}
 
 
 %install
 rm -rf $RPM_BUILD_ROOT
-cd %{builddir}
-make install DESTDIR=$RPM_BUILD_ROOT
+make -C %{_target_platform} install/fast DESTDIR=$RPM_BUILD_ROOT
 rm -r $RPM_BUILD_ROOT/usr/share/doc/%{name}
 
 
 %check
-cd %{builddir}
+cd %{_target_platform}
 ctest
 
 
@@ -77,17 +73,16 @@
 %defattr(-,root,root,-)
 %doc AUTHORS BUGS ChangeLog COPYING GNU-LGPL NEWS README References THANKS TODO
 %{_bindir}/*
-%{_libdir}/libwbxml2.so.0*
+%{_libdir}/libwbxml2.so.*
 
 %files devel
 %defattr(-,root,root,-)
-%doc AUTHORS BUGS ChangeLog COPYING GNU-LGPL NEWS README References THANKS TODO
 %{_includedir}/*
 %{_libdir}/libwbxml2.so
 %{_libdir}/pkgconfig/libwbxml2.pc
 
 
 %changelog
-* Fri Aug 06 2010 Petr Pisar <ppisar> - 0.10.8-1
+* Tue Aug 10 2010 Petr Pisar <ppisar> - 0.10.8-1
 - 0.10.8 import
 - based on and obsoletes wbxml2-0.9.2-16

The spec is sane except one minor issue:

# no line terminator, add one
echo >> THANKS
echo >> BUGS

You should either move those two lines or keep timestamps after modifying those two files, otherwise it'll cause multilib conflict. Since no line terminator is not a warning or error in rpmlint, I suggest to simply move those lines from spec.

I choose to preserve the time stamps. I replaced spec and SRPM.

OK, this package is approved.

New Package SCM Request
=======================
Package Name: libwbxml
Short Description: Library and tools to parse, encode and handle WBXML documents
Owners: ppisar awjb
Branches: f13 f14
InitialCC:

Git done (by process-git-requests).

Thanks for review and repositories.

Once libwbxml reaches stable status I will retire wbxml2 in F15--13.

Re: comment 9

It is no issue at all. File timestamps don't cause multilib conflicts. File _contents_ do, including ASCII timestamps put _into_ a file (which sometimes happens for generated documentation).

(In reply to comment #15)
> Re: comment 9
> 
> It is no issue at all. File timestamps don't cause multilib conflicts. File
> _contents_ do, including ASCII timestamps put _into_ a file (which sometimes
> happens for generated documentation).

Thanks for the clarification, the last time I have a problem with file conflict is someone gzip man pages manually in spec, so I consider all non-ELF files should have the same timestamps mistakenly to avoild multilib conflict.