Bug 859795 - Review Request: sha - File hashing utility
Review Request: sha - File hashing utility
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Guillermo Gómez
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 857639
  Show dependency treegraph
 
Reported: 2012-09-24 00:43 EDT by Eduardo Echeverria
Modified: 2013-01-24 16:58 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-24 16:53:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
guillermo.gomez: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Eduardo Echeverria 2012-09-24 00:43:56 EDT
Spec URL: http://echevemaster.fedorapeople.org/sha/sha.spec
RPMS URL: http://echevemaster.fedorapeople.org/sha/sha-1.0.4a-1.fc17.src.rpm

Description: file hashing utility that uses the
SHA-1, SHA-256, SHA-384, & SHA-512 hash algorithms.
It can be used for file integrity checking, 
remote file comparisons, etc. 
The portable algorithm implementations 
can be useful in other projects too

Fedora Account System Username: echevemaster

######################### rpmlint SRPMS ######################################
rpmlint -v sha-1.0.4a-1.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 RPMS ######################################
rpmlint -v sha-1.0.4a-1.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=4518964

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

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

Koji Build F16
http://koji.fedoraproject.org/koji/taskinfo?taskID=4518971
Comment 1 Mario Blättermann 2012-09-26 15:04:39 EDT
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.
Comment 2 Eduardo Echeverria 2012-09-27 02:43:44 EDT
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
Comment 3 Guillermo Gómez 2012-10-02 15:37:08 EDT
I'll review...
Comment 4 Guillermo Gómez 2012-10-02 15:40:05 EDT
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.
Comment 5 Eduardo Echeverria 2012-10-04 14:59:10 EDT
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
Comment 6 Guillermo Gómez 2012-10-20 09:48:04 EDT
Please review ownership of files and directories.

Sample

%files
%{_mandir}/*/*     << claims ownership of /usr/share/man/man1 which is wrong.
Comment 7 Eduardo Echeverria 2012-10-22 19:35:26 EDT
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
Comment 8 Guillermo Gómez 2012-10-26 06:38:44 EDT
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.
Comment 9 Eduardo Echeverria 2012-10-28 21:36:18 EDT
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
Comment 10 Guillermo Gómez 2012-10-29 14:46:18 EDT
:) nice job.

APPROVED
Comment 11 Eduardo Echeverria 2012-10-30 09:30:07 EDT
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
Comment 12 Gwyn Ciesla 2012-10-30 09:55:52 EDT
Git done (by process-git-requests).
Comment 13 Fedora Update System 2012-10-30 22:49:57 EDT
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
Comment 14 Fedora Update System 2012-10-30 23:04:21 EDT
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
Comment 15 Fedora Update System 2012-10-30 23:14:59 EDT
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
Comment 16 Fedora Update System 2012-10-31 14:13:06 EDT
sha-1.0.4b-1.fc18 has been pushed to the Fedora 18 testing repository.
Comment 17 Steve Grubb 2012-11-12 06:54:42 EST
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.
Comment 18 Guillermo Gómez 2012-11-12 09:44:28 EST
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.
Comment 19 Matthias Runge 2012-11-16 03:13:25 EST
(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.
Comment 20 Steve Grubb 2012-11-16 09:04:45 EST
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.
Comment 21 Guillermo Gómez 2012-11-16 10:38:29 EST
(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. :)
Comment 22 Fedora Update System 2012-12-20 11:24:22 EST
sha-1.0.4b-1.fc18 has been pushed to the Fedora 18 stable repository.
Comment 23 Michael Schwendt 2012-12-20 13:43:18 EST
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.
Comment 24 Matthias Runge 2012-12-21 07:28:02 EST
I agree with Michael, so please change this package, create a subdir!
Comment 25 Michael Schwendt 2012-12-21 16:22:30 EST
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
Comment 26 Eduardo Echeverria 2012-12-21 18:52:55 EST
 (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.
Comment 27 Fedora Update System 2012-12-23 14:25:17 EST
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
Comment 28 Fedora Update System 2012-12-23 14:43:19 EST
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
Comment 29 Fedora Update System 2012-12-23 15:02:06 EST
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
Comment 30 Fedora Update System 2012-12-23 17:43:42 EST
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).
Comment 31 Guillermo Gómez 2012-12-27 16:50:05 EST
(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 !
Comment 32 Fedora Update System 2013-01-24 16:53:14 EST
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.
Comment 33 Fedora Update System 2013-01-24 16:56:26 EST
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.
Comment 34 Fedora Update System 2013-01-24 16:58:30 EST
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.

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