I can give you a (unofficial) review for your package, but you'll still need a
sponsor to approve it for you since you are not already sponsored.

Yes, I would like that.

Here are links to the latest files:
http://downloads.sourceforge.net/dfu-programmer/dfu-programmer-0.4.1-1.src.rpm?download
http://downloads.sourceforge.net/dfu-programmer/dfu-programmer-0.4.1-1.spec?download

Sorry, bad URLs before.  These links should work after the spec file is propagated.

http://downloads.sourceforge.net/dfu-programmer/dfu-programmer-0.4.1-1.spec?use_mirror=osdn
http://downloads.sourceforge.net/dfu-programmer/dfu-programmer-0.4.1-1.src.rpm?use_mirror=easynews

Package Review
==============

Key:
 - = N/A
 x = Check
 ! = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [x] Package is named according to the Package Naming Guidelines.
 [x] Spec file name must match the base package %{name}, in the format %{name}.spec.
 [x] Package meets the Packaging Guidelines.
 [x] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested on: FC-6 / i386
 [!] Rpmlint output:
       W: dfu-programmer incoherent-version-in-changelog 0.3.1-1 0.4.1-1.fc6
 [x] Package is not relocatable.
 [x] Buildroot is correct
(%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n))
 [x] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.
 [x] License field in the package spec file matches the actual license.
     License type: GPL
 [x] If (and only if) the source package includes the text of the license(s) in
its own file, then that file, containing the text of the license(s) for the
package is included in %doc.
 [x] Spec file is legible and written in American English.
 [!] Sources used to build the package matches the upstream source, as provided
in the spec URL.
     MD5SUM this package    : 100113bd773ec1a6a6a0e67cde928b6e
     MD5SUM upstream package: 197e49052a305ee3677f2ef95a1390c9
 [x] Package is not known to require ExcludeArch, OR:
     Arches excluded:
     Why:
 [x] All build dependencies are listed in BuildRequires, except for any that are
listed in the exceptions section of Packaging Guidelines.
 [-] The spec file handles locales properly.
 [-] ldconfig called in %post and %postun if required.
 [x] Package must own all directories that it creates.
 [-] Package requires other packages for directories it uses.
 [x] Package does not contain duplicates in %files.
 [x] Permissions on files are set properly.
 [x] Package has a %clean section, which contains rm -rf %{buildroot} (or
$RPM_BUILD_ROOT).
 [x] Package consistently uses macros.
 [x] Package contains code, or permissable content.
 [-] Large documentation files are in a -doc subpackage, if required.
 [x] Package uses nothing in %doc for runtime.
 [-] Header files in -devel subpackage, if present.
 [-] Static libraries in -devel subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [-] Development .so files in -devel subpackage, if present.
 [x] Fully versioned dependency in subpackages, if present.
 [x] Package does not contain any libtool archives (.la).
 [-] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [x] Package does not own files or directories owned by other packages.

=== SUGGESTED ITEMS ===
 [x] Latest version is packaged.
 [x] Package does not include license text files separate from upstream.
 [-] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
 [x] Reviewer should test that the package builds in mock.
     Tested on: FC-6 / i386
 [x] Package should compile and build into binary rpms on all supported
architectures.
     Tested on: koji dist-fc7
 [x] Package functions as described.
 [-] Scriptlets must be sane, if used.
 [-] The placement of pkgconfig(.pc) files are correct.
 [-] File based requires are sane.


=== Issues ===
1. %changelog versions is not in sync with actual version.
2. Source0 should be a download URL.  Please see
http://fedoraproject.org/wiki/PackagingDrafts/SourceUrl#head-27442167fe28eb345470e8db56716d62b508978c
3. Normally, you'd want to use the equivalent of wget -N to download the source
tarball, but since you'd upstream, you would want to do whatever you should to
preserver the original timestamp to pack into the SRPM.
4. md5sum of the included tarball and the upstream tarball do not match.  That's
not good ;)


=== Final Notes ===
1. If you are only supporting Fedora, you don't need to specify >= 0.1.10a for
your libusb (FC5 is lowest supported and it's 0.1.11).  If you want to support
other distros or even EPEL, then you should leave it as is.
2. If your package requires kernel support at a specific version, you'd want to
add that as a requirement as well.  I don't have enough documentation to
determine if that is the case or not.


If you have any questions about these comments, let me know.

Thank you for reviewing my package.

I think I've made the corrections to Issues 1 and 2.  So for 3 and 4, should I
build the distro tarball, copy it over to my SOURCES dir, then rpmbuild the rpm
and upload the tarball, rpm & srpm to SF?  Or did I not understand quite right?

Thanks for the information in the final notes.  I seem to have the good fortune
of people from several distros using this code, so I'm going to leave it in.  I
don't know about any kernel requirements I have since I don't directly interact
with the kernel.

So from here, should I rev my project to 0.4.2 with the updates & re-post?  Are
there any actions I should take beyond that?

Thanks,
Wes

(In reply to comment #5)
> I think I've made the corrections to Issues 1 and 2.  So for 3 and 4, should I
> build the distro tarball, copy it over to my SOURCES dir, then rpmbuild the rpm
> and upload the tarball, rpm & srpm to SF?  Or did I not understand quite right?

Unless I'm misunderstanding you, you'll want to:
1) update your spec file in your version control to add a new changelog line
consistent with the version you are about to release (say 0.4.2-1)
2) make your tarball
3) make your rpm based off the spec you just updated

when you are done, you should be able to extract the tarball from your srpm (rpm
-ivh mypackage.src.rpm) and md5sum both that and the tarball that you you
started with and they will be the same.

As far as the timestamp, I'm assuming that sf.net respects preserving timestamps
on upload.  So then the tarball on your disk, in the srpm, and uploaded all have
the same timestamp.
 
> So from here, should I rev my project to 0.4.2 with the updates & re-post?  Are
> there any actions I should take beyond that?

If you follow what I'm talking about go ahead, else if you want me to look at
your spec file one more time, just post it here (go ahead an update with the
changelog you're going to use for the next release first so I can see how it's
going to be when you release it).  Just attach it on this bug report if you want.

Is anything happening with this package?  There's been no response from the
submitter after receiving commentary two months ago.

Setting NEEDINFO; I will close this ticket soon if there is no response.

I just make a pass at fixing the problems identified.  I updated the revision to
0.4.2 at the following URL:
 
http://sourceforge.net/project/showfiles.php?group_id=147246

What else do I need to do?

Thanks for the update.  There's really very little to this package, and while I
have no understanding of the application itself and no possible way to test
this, I doubt anyone else in the reviewer pool does either, so I'll go ahead and
finish up this review.

I note that the %{?dist} tag is not present.  This is not an absolute
requirement, but I need to make sure you understand how you maintain multiple
branches and the necessary orderings between them without out it.  (And if you
have to ask how you do that, you probably just want to add the dist tag and be
happy.)  See http://fedoraproject.org/wiki/Packaging/DistTag for more info.

You don't need the manual libusb runtime dependency, and in fact it's
misleading.  rpm will find the appropriate library dependency by itself, so
there's no reason to tell it.  The built package won't work with any libusb with
the required version, it will work with only a libusb package that provides the
version of the libusb library that it was built against.  It's best to just let
RPM figure things out, which it does quite well in this case.

Review:
* source files match upstream:
   eef7c56d4915880c1faa67d6b20be727352f5002955a29bbd24020462f733792  
   dfu-programmer-0.4.2.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
X dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text included in package.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks complete.
* rpmlint is silent.
X final provides and requires has unneeded libusb dependency.
   dfu-programmer = 0.4.2-1
  =
X  libusb >= 0.1.10a
   libusb-0.1.so.4()(64bit)

* %check is not present; no test suite upstream.  I haven't the hardware needed 
   to test this.
* 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.
* no scriptlets present.
* 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 static libraries.
* no libtool .la files.

Ping?

I'm not sure what happened to my last comment - I have updated the package and
it is located at:

http://sourceforge.net/project/showfiles.php?group_id=147246

OK, all of the complaints I had above are fixed.  However, since that initial
review, our guidelines for the License: tag have changed.  I believe this
package is under the GPL, version 2 or any later version, so the License: tag
should read "GPLv2+".

I'll go ahead and approve this package and you can fix the License: tag when you
check in.  I believe you'll also need to apply for sponsorship. 
http://fedoraproject.org/wiki/PackageMaintainers/Join has the details of the
process; you're probably at "Get a Fedora Account".

APPROVED

So I did the sponsorship dance a while back when you made the request; do you
need help making your CVS request and getting this package imported, built and
released?

New Package CVS Request
=======================
Package Name: dfu-programmer
Short Description: USB DFU based programmer for Atmel chips
Owners: schmidtw
Branches: F-7 EL-5
InitialCC:
Cvsextras Commits: no

I'm not quite sure what to do - is this right?

I'm trying to follow:
http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure

Yes, that request is correct. cvs done. 

Thanks for your help - it looks like I was able to complete the process.