Spec URL: http://theory.physics.helsinki.fi/~jzlehtol/rpms/cnucnu.spec SRPM URL: http://theory.physics.helsinki.fi/~jzlehtol/rpms/cnucnu-0-1.20100101.fc12.src.rpm Upstream URL: http://fedoraproject.org/wiki/Upstream_Release_Monitoring Description: Cnucnu provides an upstream release monitoring service with bugzilla integration. See more at the project homepage at http://fedoraproject.org/wiki/Upstream_Release_Monitoring
cc Till
A few questions: - Why don't you remove the .git directory prior to tarring? That would make the source smaller. - Release number seems wrong. According to http://fedoraproject.org/wiki/Packaging:NamingGuidelines#NonNumericRelease it should be 0.1.%{date} - Although the Group tag is somewhat obsolete, for me Development/Tools sounds like a better choice.
Done. http://theory.physics.helsinki.fi/~jzlehtol/rpms/cnucnu.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/cnucnu-0-0.2.20100105.fc12.src.rpm
Btw. gitweb also provides a URL to a tgz archive, e.g.: http://fedorapeople.org/gitweb?p=till/public_git/cnucnu.git;a=commit;h=2db83a6c2ad1685a3d44caf435e702c5991732d1 or http://fedorapeople.org/gitweb?p=till/public_git/cnucnu.git;a=snapshot;sf=tgz And ./setup.py sdist will also create a tarball directly from the checkout.
Could you please use the snapshots provided by gitweb or setup.py? That would make it easier for me to compare the upstream tarball to the tarball you provide in the snapshot.
Done. http://theory.physics.helsinki.fi/~jzlehtol/rpms/cnucnu.spec http://theory.physics.helsinki.fi/~jzlehtol/rpms/cnucnu-0-0.3.20100110.fc12.src.rpm
Here's the review: [!] source files match upstream: 1f4ce6c898cbf0472a2ab9871ecbe2429c89ceb91424f45bddc7324c92da051e cnucnu-7b50751529ece79992f1dc2bd16c7931929214c3.tar.gz 43c64f843f378348819eeb3b449da17a51139414c56e39c2cb839b00b82cad91 cnucnu-7b50751529ece79992f1dc2bd16c7931929214c3.tar.gz.orig [+] package meets naming and versioning guidelines. [+] spec is properly named, cleanly written, and uses macros consistently. [+] dist tag is present. [+] build root is correct. [+] license field matches the actual license. [+] license is open source-compatible. [+] license text included in package. [+] latest version is being packaged. [+] BuildRequires are proper. [NA] compiler flags are appropriate. [+] %clean is present. [+] package builds in mock. [+] package installs properly. [NA] debuginfo package looks complete. [+] rpmlint is silent. [+] final provides and requires are sane [NA] %check is present and all tests pass: [NA] no shared libraries are added to the regular linker search paths. [+] owns the directories it creates. [+] doesn't own any directories it shouldn't. [+] no duplicates in %files. [+] file permissions are appropriate. [NA] scriptlets match those on ScriptletSnippets page. [+] code, not content. [+] documentation is small, so no -docs subpackage is necessary. [+] %docs are not necessary for the proper functioning of the package. [+] no headers. [+] no pkgconfig files. [+] no libtool .la droppings. [NA] desktop files valid and installed properly. The only thing keeping me from approving this package is that I still can't verify the integrity of the snapshot. This is a bit odd because a diff -qrN against the extracted files of the provided source and the extracted files of the snapshot I downloaded clearly tells me that there is no difference. Maybe that is due to the way gitweb creates it's snapshots. However I would feel more comfortable if someone else could confirm this.
(In reply to comment #7) > The only thing keeping me from approving this package is that I still can't > verify the integrity of the snapshot. This is a bit odd because a diff -qrN > against the extracted files of the provided source and the extracted files of > the snapshot I downloaded clearly tells me that there is no difference. > Maybe that is due to the way gitweb creates it's snapshots. However I would > feel more comfortable if someone else could confirm this. The tarballs from gitweb differ in the MTIME of the tar file, which is stored in the header of gzip: http://www.gzip.org/zlib/rfc-gzip.html#file-format If you just apply gunzip on the tar.gz files, you will notice, that the uncompressed tarballs are identical.
Thank you for the information. This I can confirm: 3a36ce2d5f151b283fa5d43d6fff905d9f1fab31be89a829b482239a08a57e68 cnucnu-7b50751529ece79992f1dc2bd16c7931929214c3.tar 3a36ce2d5f151b283fa5d43d6fff905d9f1fab31be89a829b482239a08a57e68 /home/felix/Downloads/cnucnu-7b50751529ece79992f1dc2bd16c7931929214c3.tar So this package is APPROVED!
Thanks for the review. Till: do you want ownership as the developer? I can maintain, too, but you probably know better than me when something important changes in the code :)
(In reply to comment #10) > Thanks for the review. > > Till: do you want ownership as the developer? I can maintain, too, but you > probably know better than me when something important changes in the code :) That's a kind of odd question. For my needs, every commit is important, because I typically run the version that's in HEAD as the service for Fedora. I assumed that you need the software in one of your projects and therefore packaged it for easier deployment. In the packaged version, there should probably also be some stability, which I do not guarantee in the source code, since I both manage the list on the Fedora wiki and the source code itself and can therefore keep both in sync. Therefore I'd prefer not to be the owner, but I do not mind being co-maintainer.
OK. Basically I submitted this for review since I wanted to be able to run cnucnu in shell mode to check if the regexps were OK. New Package CVS Request ======================= Package Name: cnucnu Short Description: Upstream release monitoring with bug reporting Owners: jussilehtola till Branches: F-11 F-12 InitialCC:
CVS done (by process-cvs-requests.py)
cnucnu is built and available everywhere.