Bug 615695

The package looks almost fine to me. However, I recommend to be more specific in the %file sections:

%files
%defattr(-,root,root,-)
%doc COPYING AUTHORS
%dir %{_datadir}/backup-framework/
%dir %{_datadir}/backup-framework/applications/
%{_libdir}/%{name}.so.*
%{_datadir}/backup-framework/applications/accounts.conf

%files devel
%defattr(-,root,root,-)
%{_libdir}/%{name}.so
%{_libdir}/pkgconfig/%{name}.pc
%{_includedir}/%{name}/

Also, file ChangeLog doesn't contain the changelogs but refers to running git-log to get them. Thus, you should drop this file for now.

The SRPM referenced in the spec file is no longer available upstream. Instead of extracting the tarball from a temporarily available SRPM, I suggest to get a snapshot from the git repo.

New SRPM and SPEC:

http://dl.dropbox.com/u/1338197/1/libaccounts-glib-0.39-2.fc13.src.rpm
http://dl.dropbox.com/u/1338197/1/libaccounts-glib.spec

Notes: 
I add a permanent link for meego SRPM, getting snapshots for dozens of packages from git repo is not easy for both packagers and reviewers.

(In reply to comment #2)
> I add a permanent link for meego SRPM, getting snapshots for dozens of packages
> from git repo is not easy for both packagers and reviewers.    

OK, that's fine for me. The package is ready now and we can finish here.


$ rpmlint /var/lib/mock/fedora-13-x86_64/result/*.rpm
libaccounts-glib.src: W: no-cleaning-of-buildroot %clean
libaccounts-glib.src: W: no-buildroot-tag
libaccounts-glib.src: W: no-%clean-section
libaccounts-glib.src: W: invalid-url Source0: libaccounts-glib-0.39.tar.gz
libaccounts-glib-devel.x86_64: W: no-documentation
4 packages and 0 specfiles checked; 0 errors, 5 warnings.

- warning 1-3 can be ignored (package is intended to be build for 
  F-13 and later only)
- warning 4 can be ignored (upstream doesn't provide a source tarball)
- warning 5 can be ignored (tarball doesn't contain docs yet)

---------------------------------
Key:

[+] OK
[.] OK, not applicable
[X] needs work
---------------------------------

[+] MUST: The package must be named according to the Package Naming Guidelines.
[+] MUST: The spec file name must match the base package %{name}.
[+] MUST: The package must meet the Packaging Guidelines.
[+] MUST: The package must be licensed with a Fedora approved license.
    - LGPLv2 according to source headers and COPYING

[+] MUST: The License field in the package spec file must match the actual license.
[+] MUST: The file containing the text of the license(s) for the package must be included in %doc.
[+] MUST: The spec file must be written in American English.
[+] MUST: The spec file for the package MUST be legible.
[+] MUST: The sources used to build the package must match the upstream source.
    $ md5sum libaccounts-glib-0.39.tar.gz*
    52f6da83a66c8800c2e4b300ee7dd160  libaccounts-glib-0.39.tar.gz
    52f6da83a66c8800c2e4b300ee7dd160  libaccounts-glib-0.39.tar.gz.upstream

[+] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.
    koji scratch build:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=2346523

[.] MUST: If the package does not successfully compile, build or work on an architecture, ...
[+] MUST: All build dependencies must be listed in BuildRequires.
[.] MUST: The spec file MUST handle locales properly.
    - no locales

[+] MUST: Packages storing shared library files must call ldconfig in %post and %postun.
[+] MUST: Packages must NOT bundle copies of system libraries.
[.] MUST: If the package is designed to be relocatable, ...
    - not relocatable

[+] MUST: A package must own all directories that it creates. 
[+] MUST: A Fedora package must not list a file more than once in %files.
[+] MUST: Permissions on files must be set properly.
[+] MUST: Each package must consistently use macros.
[+] MUST: The package must contain code, or permissable content.
[.] MUST: Large documentation files must go in a -doc subpackage.
    - no large docs

[+] MUST: Files in %doc must not affect the runtime of the application.
[+] MUST: Header files must be in a -devel package.
[.] MUST: Static libraries must be in a -static package.
    - no static libs packaged

[+] MUST: library files that end in .so must go in a -devel package.
[+] MUST: devel packages must require the base package using a fully versioned dependency
[+] MUST: Packages must NOT contain any .la libtool archives.
[.] MUST: Packages containing GUI applications ...
    - no GUI

[+] MUST: Packages must not own files or directories already owned by other packages.
[+] MUST: All filenames in rpm packages must be valid UTF-8.

[.] SHOULD: If the source package does not include license text(s)...
    - license text is present

[+] SHOULD: The reviewer should test that the package builds in mock.
[+] SHOULD: The package should compile and build into binary rpms on all supported architectures.
[+] SHOULD: The reviewer should test that the package functions as described.
    - seems to work as expected

[+] SHOULD: If scriptlets are used, those scriptlets must be sane.
[.] SHOULD: Subpackages other than devel should require the base package. 
[+] SHOULD: pkgconfig(.pc) files should be placed in a -devel pkg.
[.] SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin ...

----------------
Package APPROVED
----------------

Thanks for the quick review, Martin!

New Package CVS Request
=======================
Package Name: libaccounts-glib
Short Description: Nokia Maemo Accounts base library
Owners: supercyper
Branches:
InitialCC:

(In reply to comment #3)
> (In reply to comment #2)
> > I add a permanent link for meego SRPM, getting snapshots for dozens of packages
> > from git repo is not easy for both packagers and reviewers.    
> 
> OK, that's fine for me. The package is ready now and we can finish here.
> 

It seems some meego packages is weird in git repo, the git HEAD is older than packages in the meego SRPM.

(In reply to comment #6)
> It seems some meego packages is weird in git repo, the git HEAD is older than
> packages in the meego SRPM.    

That's strange. Maybe you should contact the upstream developers and ask them to push the changes in their local repos to the public one.

CVS done (by process-cvs-requests.py).