Bug 211761 - Review Request: dfu-programmer - USB DFU based programmer for Atmel chips
Review Request: dfu-programmer - USB DFU based programmer for Atmel chips
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
Depends On:
  Show dependency treegraph
Reported: 2006-10-22 02:51 EDT by Weston Schmidt
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-27 03:13:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
tibbs: fedora‑review+
kevin: fedora‑cvs+

Attachments (Terms of Use)

  None (edit)
Description Weston Schmidt 2006-10-22 02:51:40 EDT
Spec URL: http://prdownloads.sourceforge.net/dfu-programmer/dfu-programmer.spec?download
SRPM URL: http://prdownloads.sourceforge.net/dfu-programmer/dfu-programmer-0.3.1-1.src.rpm?download

dfu-programmer is a Device Firmware Update based USB programmer for Atmel chips with a USB bootloader.  (More info is at: http://dfu-programmer.sourceforge.net/ )

I have been working on this project for over a year I would like to have it available for everyone using Fedora via the Fedora Extras.
Comment 1 Bernard Johnson 2007-05-04 00:53:34 EDT
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.
Comment 4 Bernard Johnson 2007-05-06 00:56:16 EDT
Package Review

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

 [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:
 [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
 [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
 [x] Package does not own files or directories owned by other packages.

 [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
     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
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.
Comment 5 Weston Schmidt 2007-05-08 03:52:28 EDT
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?

Comment 6 Bernard Johnson 2007-05-08 04:41:20 EDT
(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.
Comment 7 Jason Tibbitts 2007-07-06 15:27:57 EDT
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.
Comment 8 Weston Schmidt 2007-07-07 03:14:13 EDT
I just make a pass at fixing the problems identified.  I updated the revision to
0.4.2 at the following URL:

What else do I need to do?
Comment 9 Jason Tibbitts 2007-07-08 14:30:39 EDT
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.
Comment 10 Jason Tibbitts 2007-07-08 21:05:32 EDT
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.

* source files match upstream:
* 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

* %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.
Comment 11 Jason Tibbitts 2007-07-19 20:35:28 EDT
Comment 12 Weston Schmidt 2007-08-06 02:07:07 EDT
I'm not sure what happened to my last comment - I have updated the package and
it is located at:

Comment 13 Jason Tibbitts 2007-08-15 12:43:37 EDT
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".

Comment 14 Jason Tibbitts 2007-08-25 12:51:01 EDT
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
Comment 15 Weston Schmidt 2007-08-25 14:37:53 EDT
New Package CVS Request
Package Name: dfu-programmer
Short Description: USB DFU based programmer for Atmel chips
Owners: schmidtw
Branches: F-7 EL-5
Cvsextras Commits: no
Comment 16 Weston Schmidt 2007-08-26 03:47:21 EDT
I'm not quite sure what to do - is this right?

I'm trying to follow:
Comment 17 Kevin Fenzi 2007-08-26 17:47:25 EDT
Yes, that request is correct. cvs done. 
Comment 18 Weston Schmidt 2007-08-27 03:13:36 EDT
Thanks for your help - it looks like I was able to complete the process.

Note You need to log in before you can comment on or make changes to this bug.