Bug 859795

There are versioned libraries in the -devel package:

%{_libdir}/*.so.*

Usually, they have to be in a -libs or *lib package while the versioned library has to remain in the -devel package. If you don't want to provide an extra package (you run ldconfig anyway for the main package), remove the versioned libraries to the base package.

Moreover, %{name} = %{version}-%{release} has to be %{name}%{?_isa} = %{version}-%{release} to match the correct architecture.

What are the *.c files in the -devel package for? As far as I can see, those are no development examples, rather the source files of sha.

Hi Mario Thanks for your valuable comments, the corrected specs and SRPMS here:

############################# Corrected RPMS && Spec ##########################
Spec URL: http://echevemaster.fedorapeople.org/sha/2/sha.spec
SRPM URL: http://echevemaster.fedorapeople.org/sha/2/sha-1.0.4a-2.fc17.src.rpm

rpmlint srpm
################################################
rpmlint -v sha-1.0.4a-2.fc17.src.rpm 
sha.src: I: checking
sha.src: I: checking-url http://hg.saddi.com/sha-asaddi (timeout 10 seconds)
sha.src: I: checking-url http://www.saddi.com/software/sha/dist/sha-1.0.4a.tar.gz (timeout 10 seconds)
1 packages and 0 specfiles checked; 0 errors, 0 warnings

rpmlint rpm 
###########################################
rpmlint -v sha-1.0.4a-2.fc17.x86_64.rpm 
sha.x86_64: I: checking
sha.x86_64: I: checking-url http://hg.saddi.com/sha-asaddi (timeout 10 seconds)
1 packages and 0 specfiles checked; 0 errors, 0 warnings.


Koji Build Rawhide 
http://koji.fedoraproject.org/koji/taskinfo?taskID=4532147

Koji Build F18
http://koji.fedoraproject.org/koji/taskinfo?taskID=4532150

Koji Build f17
http://koji.fedoraproject.org/koji/taskinfo?taskID=4532153

Koji Build F16
http://koji.fedoraproject.org/koji/taskinfo?taskID=4532156

I'll review...

First comment for readers, i had a long talk with Eduardo in order to review the naming convention for this pkg since it fits the case of a post-release.

Eduardo has to workaround with upstream for the naming convention for upcoming releases, then we will move on commenting in the spec about such agreement.

I added the comment Guillermo:

Spec URL: http://echevemaster.fedorapeople.org/sha/3/sha.spec
SRPM URL: http://echevemaster.fedorapeople.org/sha/3/sha-1.0.4a-3.fc17.src.rpm

Best Regards

Please review ownership of files and directories.

Sample

%files
%{_mandir}/*/*     << claims ownership of /usr/share/man/man1 which is wrong.

Guillermo, fixed the issues: 
SPEC: http://echevemaster.fedorapeople.org/sha/4/sha.spec
SRPMS: http://echevemaster.fedorapeople.org/sha/4/sha-1.0.4a-4.fc17.src.rpm

I will only list pending issues (afaik):

===== MUST items =====

[ ]: 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.

[ ]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. 

Licenses found:
     "BSD (2 clause)", "GPL (v2 or later)", "Unknown or generated". 
     3 files have unknown license. Detailed output of licensecheck in
     /home/gomix/Fedpkg/fedora-review/859795-sha/licensecheck.txt

BSD (2 clause)
--------------
/var/lib/mock/fedora-17-x86_64/root/builddir/build/BUILD/sha-1.0.4a/sha256.c

GPL (v2 or later)
-----------------
/var/lib/mock/fedora-17-x86_64/root/builddir/build/BUILD/sha-1.0.4a/ltmain.sh

Unknown or generated
--------------------
/var/lib/mock/fedora-17-x86_64/root/builddir/build/BUILD/sha-1.0.4a/version.h

===== SHOULD items =====

[ ]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.

All the above points regarding licencing should be addressed before approving. I think a separate LICENSE file is the best solution. Some files have their own headers which is perfectly ok, but some are not covered.

Please review [1] for more details on howto proceed.

https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text

[!]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)

The %clean section is not required for F-13 and above. 
Each package for F-12 and below (or EPEL 5) MUST have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT).

Include %clean section only if you plan to release a EPEL5 version (not a breaker).

I dont see any more issues with this package to approve it :) Please try to address remaining issues, mainly licencing issues.

Hi Guillermo, I've talked with upstream and given me a tarball with separate license, here is the new specs and SRPM

SPEC: http://echevemaster.fedorapeople.org/sha/5/sha.spec
SRPMS: http://echevemaster.fedorapeople.org/sha/5/sha-1.0.4b-1.fc17.src.rpm

with respect at the file ltmain.sh,It includes a text which reads:

"As a special exception to the GNU General Public License,
if you distribute this file as part of a program or library that
is built using GNU Libtool, you may include this file under the
same distribution terms that you use for the rest of that program."

I therefore I think not necessary to include GPLv2 at the tag license

Regards

:) nice job.

APPROVED

Thanks for the review Guillermo:

New Package SCM Request
=======================
Package Name: sha
Short Description: File hashing utility
Owners: echevemaster
Branches: f16 f17 f18
InitialCC: gomix

Git done (by process-git-requests).

sha-1.0.4b-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/sha-1.0.4b-1.fc18

sha-1.0.4b-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/sha-1.0.4b-1.fc17

sha-1.0.4b-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/sha-1.0.4b-1.fc16

sha-1.0.4b-1.fc18 has been pushed to the Fedora 18 testing repository.

Why would we want more crypto? Coreutils provides sha256sum and friends. If we need it as API, libgcrypt provides it. More crypto packages is not a good thing.

In general, there's no we as "we control and decide which kind of package comes in or not in Fedora". If there's anybody interested and needing it, and does the work, and its free sw, and it does comply with Fedora Packaging Guide Lines, any package is welcome.

(In reply to comment #18)
> In general, there's no we as "we control and decide which kind of package
> comes in or not in Fedora". If there's anybody interested and needing it,
> and does the work, and its free sw, and it does comply with Fedora Packaging
> Guide Lines, any package is welcome.

Hmm, but what about two packages a and b, b is a fork of a and both are providing nearly the same? What about, if a is really actively maintained, b just a project of one person? IMHO, we exactly have the situation here? 

I'm sharing Steve's concern; basically it's the same policy as the no-bundled-libs policy (even it's not named the same way, and here's nothing bundled at all, but this policy follows the original idea).

@Steve: Do you have a suggestion, how to make duff 
https://bugzilla.redhat.com/show_bug.cgi?id=857639
work with our coreutils package? IMHO duff is the only package using this package sha.

We have other file duplication finding utils, like fdupes. 

I took a look in the code of duff and its simply using the sha package as a library rather than the standalone sha1sum utility from coreutils. Its trivial to move duff to use mhash or openssl, or libgcrypt. Not sure which is the best match for the zlib license.

(In reply to comment #19)
> (In reply to comment #18)
> > In general, there's no we as "we control and decide which kind of package
> > comes in or not in Fedora". If there's anybody interested and needing it,
> > and does the work, and its free sw, and it does comply with Fedora Packaging
> > Guide Lines, any package is welcome.
> 
> Hmm, but what about two packages a and b, b is a fork of a and both are
> providing nearly the same? 

Nearly means they are not providing exactly the same functionality.

> What about, if a is really actively maintained, b
> just a project of one person?

Actively maintained is not a term mandated by the numbers of upstream contributors, it could be one maintainer or a large community. Certainly i prefer a large community behind it ;) but that's no reason to reject a package.

> I'm sharing Steve's concern; basically it's the same policy as the
> no-bundled-libs policy (even it's not named the same way, and here's nothing
> bundled at all, but this policy follows the original idea).

hmm im not sure what exactly are yo trying to say here. no-bundled-libs policy is being respected here, sha is the result afaik.

> @Steve: Do you have a suggestion, how to make duff 
> https://bugzilla.redhat.com/show_bug.cgi?id=857639
> work with our coreutils package? IMHO duff is the only package using this
> package sha.

Thats one good point, but that's up to upstream to do. :)

sha-1.0.4b-1.fc18 has been pushed to the Fedora 18 stable repository.

This package should not have been approved. It is rude to install files with highly generic filenames, such as

  /usr/include/config.h
  /usr/include/version.h

directly into /usr/include. At least a subdirectory could have been created.

I agree with Michael, so please change this package, create a subdir!

Have had to spend some time in the guidelines...,
so reopening based upon:

* https://fedoraproject.org/wiki/Packaging:Conflicts#Potential_Conflicting_Files
* https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts

 (In reply to comment #24)
> I agree with Michael, so please change this package, create a subdir!

Thanks for the comment Matthias, I will

(In reply to comment #25)
> Have had to spend some time in the guidelines...,
> so reopening based upon:
> 
> *
> https://fedoraproject.org/wiki/Packaging:
> Conflicts#Potential_Conflicting_Files
> * https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts

If I not answered immediately does not mean that I refuse to fixed this (Remember that we are very close to Christmas) so in the next days I'll be offering a solution for this package.

sha-1.0.4b-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/sha-1.0.4b-2.fc18

sha-1.0.4b-2.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/sha-1.0.4b-2.fc17

sha-1.0.4b-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/sha-1.0.4b-2.fc16

Package sha-1.0.4b-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sha-1.0.4b-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-20907/sha-1.0.4b-2.fc18
then log in and leave karma (feedback).

(In reply to comment #23)
> This package should not have been approved. It is rude to install files with
> highly generic filenames, such as
> 
>   /usr/include/config.h
>   /usr/include/version.h
> 
> directly into /usr/include. At least a subdirectory could have been created.

Thanks for the catch !

sha-1.0.4b-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

sha-1.0.4b-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

sha-1.0.4b-2.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.