Bug 803018

Summary: Review Request: lziprecover - Data recovery tool and decompressor for files in the lzip compressed format
Product: [Fedora] Fedora Reporter: Gwyn Ciesla <gwync>
Component: Package ReviewAssignee: Richard Shaw <hobbes1069>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: hobbes1069, notting, package-review
Target Milestone: ---Flags: hobbes1069: fedora-review+
gwync: fedora-cvs+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-14 13:01:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 802973    

Description Gwyn Ciesla 2012-03-13 19:33:24 UTC
SRPM: http://fedorapeople.org/~limb/review/lziprecover/lziprecover-1.13-1.fc16.src.rpm
SPEC: http://fedorapeople.org/~limb/review/lziprecover/lziprecover.spec

Description: Lziprecover is a data recovery tool and decompressor for files in the lzip
compressed data format (.lz) able to repair slightly damaged files, recover
badly damaged files from two or more copies, extract undamaged members
from multi-member files, decompress files and test integrity of files.

Lziprecover is able to recover or decompress files produced by any of the
compressors in the lzip family; lzip, plzip, minilzip/lzlib, clzip and
pdlzip. This recovery capability contributes to make the lzip format one
of the best options for long-term data archiving.


Recently split from the lzip package, already in Fedora.

Comment 1 Richard Shaw 2012-03-13 20:16:59 UTC
The spec looks good although it's got a lot of the stuff that isn't necessary anymore unless you're going to build for EL5...

BuildRoot:
rm -rf $RPM_BUILD_ROOT in %install
%clean
%defattr in %files

Obviously not a showstopper... full review to follow.

Comment 2 Richard Shaw 2012-03-13 20:28:30 UTC
+: OK
-: must be fixed
=: should be fixed (at your discretion)
?: Question or clairification needed
N: not applicable

MUST:
[+] rpmlint output: shown in comment.
[+] follows package naming guidelines
[+] spec file base name matches package name
[+] package meets the packaging guidelines
[+] package uses a Fedora approved license: LGPLv3+
[+] license field matches the actual license.
[+] license file is included in %doc: COPYING
[+] spec file is in American English
[+] spec file is legible
[+] sources match upstream: md5 sum matches (83be32a820b5d5211431b0d6f56181a9) 
[+] package builds on at least one primary arch: Tested F16 x86_64
[N] appropriate use of ExcludeArch
[+] all build requirements in BuildRequires
[N] spec file handles locales properly
[N] ldconfig in %post and %postun
[+] no bundled copies of system libraries
[+] no relocatable packages
[N] package owns all directories that it creates
[+] no files listed twice in %files
[+] proper permissions on files
[+] consistent use of macros
[+] code or permissible content
[N] large documentation in -doc
[+] no runtime dependencies in %doc
[N] header files in -devel
[N] static libraries in -static
[N] .so in -devel
[N] -devel requires main package
[+] package contains no libtool archives
[N] package contains a desktop file, uses desktop-file-install/validate
[+] package does not own files/dirs owned by other packages
[+] all filenames in UTF-8

SHOULD:
[+] query upstream for license text
[N] description and summary contains available translations
[+] package builds in mock
[+] package builds on all supported arches: Tested x86_64
[?] package functions as described: Not tested
[+] sane scriptlets
[N] subpackages require the main package
[N] placement of pkgconfig files
[N] file dependencies versus package dependencies
[N] package contains man pages for binaries/scripts

I'm guessing it's ok but what is the purpose of Source1? I'm assuming it's some sort of signature file but it's never installed anywhere so it's only in the SRPM.

*** APPROVED ***

Comment 3 Gwyn Ciesla 2012-03-14 12:04:12 UTC
That's an excellent question I included it from the lzip spec, and I've seen several packages include them, but I've never seen anything done with them.  I suppose it would ease verification of the SRPM vs. upstream for end users.

Anyway, thanks for the review!

New Package SCM Request
=======================
Package Name: lziprecover
Short Description: Data recovery tool and decompressor for files in the lzip compressed format
Owners: limb
Branches: 
InitialCC:

Comment 4 Gwyn Ciesla 2012-03-14 12:29:10 UTC
Git done (by process-git-requests).

Comment 5 Gwyn Ciesla 2012-03-14 13:01:09 UTC
Imported and built.

Comment 6 Gwyn Ciesla 2014-09-24 10:08:41 UTC
Package Change Request
======================
Package Name: lziprecover
New Branches: el5 el6 epel7
Owners: limb

Comment 7 Gwyn Ciesla 2014-09-24 10:12:18 UTC
Git done (by process-git-requests).