Bug 502130

Running rpmlint on the final binary RPM does result in errors concerning a statically linked library that is built for targets and not to be run by OpenOCD.  Reference: https://bugzilla.redhat.com/show_bug.cgi?id=502112

I will sponsor you. Can you give me your FAS username please ?

(In reply to comment #2)
> I will sponsor you. Can you give me your FAS username please ?  
My username is dnglaze in FAS.

#1: The contents of /usr/share/openocd/contrib should go to %doc
%doc contrib/

and remove the /usr/share/openocd/contrib at the end of the %install section to avoid duplicates

#2: source url should be complete

#3: Preserve timestamps
add INSTALL="install -p"  to your make install

(In reply to comment #4)
> #1: The contents of /usr/share/openocd/contrib should go to %doc
> %doc contrib/
>
> and remove the /usr/share/openocd/contrib at the end of the %install section to
> avoid duplicates

This makes more warnings appear from rpmlint.  For some reason, doing the "fuller path" %doc %{_datadir}/%{name}/contrib/* results in no warnings.
 
> #2: source url should be complete

I think I got this done.  I replaced the URL parameter with the full path to the source tar on OpenOCD's project site.

> #3: Preserve timestamps
> add INSTALL="install -p"  to your make install  

Added this.

New links:
http://files.dinoprojects.com/openocd/openocd-0.1.0-2.fc10.src.rpm
http://files.dinoprojects.com/openocd/openocd.spec

(In reply to comment #5)
> I think I got this done.  I replaced the URL parameter with the full path to
> the source tar on OpenOCD's project site.

No actually, source0 should have the full URL for downloading the sources.

URL is the url for the upstream website.

(In reply to comment #6)
> No actually, source0 should have the full URL for downloading the sources.
> 
> URL is the url for the upstream website.  


Alright, I've finally made these updates to the spec file.  Here are the new files.  This includes a spec bump.  Thanks.

http://files.dinoprojects.com/openocd/openocd-0.1.0-3.fc11.src.rpm
http://files.dinoprojects.com/openocd/openocd.spec

I have now updated the spec file and source RPM to reflect a new version of OpenOCD that was released recently.  Koji builds are showing clean for Fedora 10 and 11.

http://files.dinoprojects.com/openocd/openocd-0.2.0-1.fc11.src.rpm
http://files.dinoprojects.com/openocd/openocd.spec

Is there any reason you are shipping static libraries ?

(In reply to comment #9)
> Is there any reason you are shipping static libraries ?  

That's my bad.  I didn't see the information on static libraries in the packaging guidelines.  There is an option to build a shared object instead, but when I do that I get the following warnings from rpmlint:

openocd.x86_64: W: shared-lib-calls-exit /usr/lib64/libopenocd.so.0.0.0 exit.5
openocd.x86_64: W: devel-file-in-non-devel-package /usr/lib64/libopenocd.so

I've removed 2 errors that have already been resolved as documented in the spec file.  I'm not sure what to do with the unversioned shared object.  According to the guidelines, this should be in the devel package.  Should I just remove the symlink?

Here are links to the version of the spec file that builds a shared object instead of a static library.

http://files.dinoprojects.com/openocd/openocd-0.2.0-2.fc11.src.rpm
http://files.dinoprojects.com/openocd/openocd.spec

#001 : ScriptletSnippets - Texinfo

Please turn the spec file with respect to the Fedora packaging guidelines as stated on 

http://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Texinfo

#002 : %prep instead of %build

Move the following to the %prep section

-------------
cd doc
iconv -f iso8859-1 -t utf-8 openocd.info > openocd.info.conv
mv -f openocd.info.conv openocd.info
-------------

#003 : Improve future commit patches and logs

Use the following style for the %configure :

%configure \
    --disable-werror \
    --disable-static \
    --enable-shared \
    --enable-parport \
    --enable-parport_ppdev \
    --enable-ft2232_libftdi 
    --enable-ep93xx \
    --enable-at91rm9200 \
    --enable-usbprog \
    --enable-presto_libftdi \
    --enable-jlink \
    --enable-vsllink \
    --enable-rlink \
    --enable-dummy \
    --enable-gw16012 \
    --enable-amtjtagaccel \
    --enable-arm-jtag-ew

This is because, when openocd will be approved and everytime you will update it, you will have to commit the srpm to fedora cvs repositories. For each commit, a log message (a patch-like message) will automatically be sent to the fedora-cvs-commits mailing list, hence it would be nice that the updated item can be easily spotted in the logs.

#004: Build requires:

libftdi-devel already requires libusb-devel see

$ rpm -qR libftdi-devel

Remove libusb-devel from the buildrequires

(In reply to comment #11)

I made changes #1-4.  I also switched back to a static library, but removed the library from the distribution.  This was suggested by upstream.  Here is the new spec file and SRPM.

http://files.dinoprojects.com/openocd/openocd-0.2.0-3.fc11.src.rpm
http://files.dinoprojects.com/openocd/openocd.spec

I sponsored you as a Fedora packager with its relative rights.

The package looks good to me except the following warnings are found during the rpmbuild


warning: File listed twice: /usr/share/openocd/contrib/libdcc
warning: File listed twice: /usr/share/openocd/contrib/libdcc/README
warning: File listed twice: /usr/share/openocd/contrib/libdcc/dcc_stdio.c
warning: File listed twice: /usr/share/openocd/contrib/libdcc/dcc_stdio.h
warning: File listed twice: /usr/share/openocd/contrib/libdcc/example.c
warning: File listed twice: /usr/share/openocd/contrib/openocd.udev


To fix it, replace

%{_datadir}/%{name}

by

%dir %{_datadir}/%{name}
%{_datadir}/%{name}/scripts

[Pending] MUST: the package does not contain any duplicate files in the %files listing.
[Pending] MUST: the package owns all directories that it creates.

Fix the %files as mentioned above

---------------------------------------------------------------------------

- MUST: The package is named according to the Package Naming Guidelines.
- MUST: The spec file name matches the base package %{name}
- MUST: The package meets the Packaging Guidelines.
- MUST: The package is licensed (GPLv2) with an open-source compatible license and meet other legal requirements as defined in the legal section of Packaging Guidelines.
- MUST: The License field in the package spec file matches the actual license.
- MUST: 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.
- MUST: The spec file must be written in American English.
- MUST: The spec file for the package is be legible. 
- MUST: The sources used to build the package must matches the upstream source, as provided in the spec URL.
- MUST: The package successfully compiles and builds into binary rpms on at least i586.
- MUST: All build dependencies is listed in BuildRequires.
- MUST: The spec file handles locales properly.: No locales in this package
- MUST: the package is not designed to be relocatable
- MUST: Permissions on files are set properly.
- MUST: The package has a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).
- MUST: The package consistently uses macros, as described in the macros section of Packaging Guidelines.
- MUST: The package contains code, or permissible content. This is described in detail in the code vs. content section of Packaging Guidelines.
- MUST: There are no Large documentation files
- MUST: %doc does not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
- MUST: There are no Header files or static libraries 
- MUST: The package does not contain library files with a suffix 
- MUST: Package does NOT contain any .la libtool archives
- MUST: Package does not own files or directories already owned by other packages. 

SHOULD Items:

 - SHOULD: The source package does include license text(s) as COPYING
 - SHOULD: mock builds succcessfully in i586.
 - SHOULD: The reviewer tested that the package functions as described. A
package should not segfault instead of running, for example.
 - SHOULD:  Those scriptlets used are sane. 
 - SHOULD: No subpackages present.



Update the package for approval.

(In reply to comment #15)

I've updated the spec file to have the fix for the warnings about the files being listed twice.  New links given below.

http://files.dinoprojects.com/openocd/openocd-0.2.0-4.fc11.src.rpm
http://files.dinoprojects.com/openocd/openocd.spec

Approved.

Please commit the packaging process as described as from this section:
https://fedoraproject.org/wiki/PackageMaintainers/Join#Add_Package_to_CVS_and_Set_Owner

New Package CVS Request
=======================
Package Name: openocd
Short Description: Debugging, in-system programming and boundary-scan testing for embedded devices
Owners: dnglaze
Branches: F-10 F-11
InitialCC:

cvs done.

Please proceed for build and push as described in
https://fedoraproject.org/wiki/PackageMaintainers/Join#Check_out_the_module

Dean ? Are you there ?

(In reply to comment #21)
> Dean ? Are you there ?  
Yeah, I'm still here.  I've got the package uploaded, tagged, and built for devel, F-10, and F-11.  I've been swamped recently so I keep forgetting to submit the new package in Bodhi.  I went ahead and took care of this this morning.  See https://admin.fedoraproject.org/updates/openocd

Next add the bug number on bodhi while you are requesting a push. Bodhi will automatically close this package review.

I'm closing it manually.

Package Change Request
======================
Package Name: openocd
New Branches: F-12
Owners: dnglaze

My bad.  I didn't use the right command to get the F-12 branch.  Everything is fine, I'm just new at this.

FYI: https://admin.fedoraproject.org/pkgdb/packages/name/openocd

this can be handy to figure out quickly your branches.

Package Change Request
======================
Package Name: openocd
New Branches: el6
Owners:  dnglaze
InitialCC:

Git done (by process-git-requests).