Bug 803018 - Review Request: lziprecover - Data recovery tool and decompressor for files in the lzip compressed format
Review Request: lziprecover - Data recovery tool and decompressor for files i...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Shaw
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 802973
  Show dependency treegraph
 
Reported: 2012-03-13 15:33 EDT by Gwyn Ciesla
Modified: 2014-09-24 06:12 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-14 09:01:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
hobbes1069: fedora‑review+
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Gwyn Ciesla 2012-03-13 15:33:24 EDT
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 16:16:59 EDT
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 16:28:30 EDT
+: 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 08:04:12 EDT
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 08:29:10 EDT
Git done (by process-git-requests).
Comment 5 Gwyn Ciesla 2012-03-14 09:01:09 EDT
Imported and built.
Comment 6 Gwyn Ciesla 2014-09-24 06:08:41 EDT
Package Change Request
======================
Package Name: lziprecover
New Branches: el5 el6 epel7
Owners: limb
Comment 7 Gwyn Ciesla 2014-09-24 06:12:18 EDT
Git done (by process-git-requests).

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