Bug 426922 - Review Request: gpar2 - GUI for verifying and repairing PAR and PAR2 recovery sets
Review Request: gpar2 - GUI for verifying and repairing PAR and PAR2 recovery...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: manuel wolfshant
Fedora Extras Quality Assurance
:
Depends On: 426919
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-28 08:16 EST by Adel Gadllah
Modified: 2007-12-30 13:53 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-30 13:53:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
wolfy: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Adel Gadllah 2007-12-28 08:16:26 EST
Spec URL: http://tgmweb.at/gadllah/gpar2.spec
SRPM URL: http://tgmweb.at/gadllah/gpar2-0.3-1.fc8.src.rpm
Description: 
A simple, easy to use graphical interface for verification and
repairation of PAR v1.0 and PAR v2.0(PAR2) recovery sets.
Comment 1 Adel Gadllah 2007-12-28 08:17:03 EST
NOTE:
This depends on libpar2 currently under review:
https://bugzilla.redhat.com/show_bug.cgi?id=426919
Comment 2 manuel wolfshant 2007-12-28 21:12:58 EST
There are a couple of fixes needed:
- the word "repairation" used in %description does not exist in English. Please
replace it with "repair".
- you need desktop-file-utils and gettext as BRs (without desktop-file-utils,
mock build fails; without gettext, the fr gpar2.mo is not built )

I'll be happy to review your package once you fix the above.
Comment 3 Adel Gadllah 2007-12-29 05:47:10 EST
Updated srpm and spec:
http://tgmweb.at/gadllah/gpar2.spec
http://tgmweb.at/gadllah/gpar2-0.3-2.fc8.src.rpm
Comment 4 manuel wolfshant 2007-12-29 08:27:04 EST
Package Review
==============

Key:
 - = N/A
 x = Check
 ! = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [x] Package is named according to the Package Naming Guidelines.
 [x] Spec file name must match the base package %{name}, in the format %{name}.spec.
 [x] Package meets the Packaging Guidelines.
 [x] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested on:x86_64
 [!] Rpmlint output:
        Source RPM: empty
        rpmlint of gpar2:
                gpar2.x86_64: W: incoherent-version-in-changelog 0.3-1 0.3-2.fc9
--> that's an easy one, you forgot to bump the release when doing copy/paste in
the changelog. Just fix it before uploading to cvs.
 [x] Package is not relocatable.
 [x] Buildroot is correct
(%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n))
 [x] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.
 [x] License field in the package spec file matches the actual license.
     License type:GPLv2+
 [x] 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.
 [x] Spec file is legible and written in American English.
 [x] Sources used to build the package matches the upstream source, as provided
in the spec URL.
     SHA1SUM of package: 0ae966d4f29ced3d076a60e99722bee08a53c570 gpar2-0.3.tar.gz
 [x] Package is not known to require ExcludeArch
 [x] All build dependencies are listed in BuildRequires, except for any that are
listed in the exceptions section of Packaging Guidelines.
 [x] The spec file handles locales properly.
 [-] ldconfig called in %post and %postun if required.
 [x] Package must own all directories that it creates.
 [x] Package requires other packages for directories it uses.
 [x] Package does not contain duplicates in %files.
 [x] Permissions on files are set properly.
 [x] Package has a %clean section, which contains rm -rf %{buildroot} (or
$RPM_BUILD_ROOT).
 [x] Package consistently uses macros.
 [x] Package contains code, or permissable content.
 [-] Large documentation files are in a -doc subpackage, if required.
 [x] Package uses nothing in %doc for runtime.
 [x] Header files in -devel subpackage, if present.
 [-] Static libraries in -devel subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [x] Development .so files in -devel subpackage, if present.
 [x] Fully versioned dependency in subpackages, if present.
 [x] Package does not contain any libtool archives (.la).
 [!] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [x] Package does not own files or directories owned by other packages.


=== SUGGESTED ITEMS ===
 [x] Latest version is packaged.
 [x] Package does not include license text files separate from upstream.
 [x] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available. Please also see
my comment number 2 below
 [x] Reviewer should test that the package builds in mock.
     Tested on:devel/x86_64
 [x] Package should compile and build into binary rpms on all supported
architectures.
     Tested on:devel/x86_64
 [x] Package functions as described.
 [!] Scriptlets must be sane, if used.
 [-] The placement of pkgconfig(.pc) files are correct.
 [-] File based requires are sane.


=== Issues ===
1.  according to
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?highlight=%28ScriptletSnippets%29#head-de6770dd9867fcd085a73a4700f6bcd0d10294ef
the presence of a mimetype entry in the desktop file imposes the need for
 %post
 update-desktop-database &> /dev/null || :
 %postun
 update-desktop-database &> /dev/null || :
2. According to
http://fedoraproject.org/wiki/Packaging/Guidelines#head-254ddf07aae20a23ced8cecc219d8f73926e9755,
the desktop file uses a value for Categories which no longer corresponds to our
current specifications (it should not contain Application any more). Looking at
http://standards.freedesktop.org/menu-spec/latest/apa.html I'd say Utility would
fit the bill here.
3. Don't forget to fix the changelog entry :)



=== Comments ===
1. I admit being puzzled by the fact that the French gpar2.mo is built, despite
gettext not being present as a BR:
checking whether NLS is requested... yes
checking for msgfmt... no
checking for gmsgfmt... no:
checking for xgettext... no
checking for msgmerge... no
 And yet gpar2.mo is correctly built and included, so it's OK.
2. Just a suggestion: you could take the French description from the desktop
file and use it as %description[fr] in the spec.


Please fix the issues above mentioned and I will approve the package.
Comment 5 Adel Gadllah 2007-12-29 09:07:16 EST
(In reply to comment #4)

>  [!] Rpmlint output:
>         Source RPM: empty
>         rpmlint of gpar2:
>                 gpar2.x86_64: W: incoherent-version-in-changelog 0.3-1 0.3-2.fc9
> --> that's an easy one, you forgot to bump the release when doing copy/paste in
> the changelog. Just fix it before uploading to cvs.

fixed.

>  [x] Description and summary sections in the package spec file contains
> translations for supported Non-English languages, if available. Please also see
> my comment number 2 below

>  [!] Scriptlets must be sane, if used.

> === Issues ===
> 1.  according to
>
http://fedoraproject.org/wiki/Packaging/ScriptletSnippets?highlight=%28ScriptletSnippets%29#head-de6770dd9867fcd085a73a4700f6bcd0d10294ef
> the presence of a mimetype entry in the desktop file imposes the need for
>  %post
>  update-desktop-database &> /dev/null || :
>  %postun
>  update-desktop-database &> /dev/null || :


fixed

> 2. According to
>
http://fedoraproject.org/wiki/Packaging/Guidelines#head-254ddf07aae20a23ced8cecc219d8f73926e9755,
> the desktop file uses a value for Categories which no longer corresponds to our
> current specifications (it should not contain Application any more). Looking at
> http://standards.freedesktop.org/menu-spec/latest/apa.html I'd say Utility would
> fit the bill here.

fixed

> 3. Don't forget to fix the changelog entry :)

;)

> === Comments ===
> 1. I admit being puzzled by the fact that the French gpar2.mo is built, despite
> gettext not being present as a BR:
> checking whether NLS is requested... yes
> checking for msgfmt... no
> checking for gmsgfmt... no:
> checking for xgettext... no
> checking for msgmerge... no
>  And yet gpar2.mo is correctly built and included, so it's OK.

OK I somehow forgot to add it while doing the last fixes but if it works this
way .. ;)

> 2. Just a suggestion: you could take the French description from the desktop
> file and use it as %description[fr] in the spec.

I can but I preffered not to do so to make keep the spec file cleaner; thats
whats specspo is for afterall.

> Please fix the issues above mentioned and I will approve the package.

New spec / srpm:
http://tgmweb.at/gadllah/gpar2.spec
http://tgmweb.at/gadllah/gpar2-0.3-3.fc8.src.rpm
Comment 6 manuel wolfshant 2007-12-29 16:18:54 EST
The food news is that all problems mentioned above are fixed.
The bad news is that I think that a program should fail if the proper BR are not
met. Since in this specific situation the build does not fail in the absence of
gettext, I have been investigating a bit more and I think that we have a problem. 


I did a diff between the build logs with and without gettext as BR and the only
differences I did spot in the build log are
< checking for msgfmt... /usr/bin/msgfmt
< checking for gmsgfmt... /usr/bin/msgfmt
< checking for xgettext... /usr/bin/xgettext
< checking for msgmerge... /usr/bin/msgmerge
---
> checking for msgfmt... no
> checking for gmsgfmt... :
> checking for xgettext... no
> checking for msgmerge... no

After that I decided to look at the source and voila: it looks to me that gpar2
ships both it's own private copy of gettext and also a fr.gmo file which is
simply copied as such to the final .pot file. I have tried to do a mock build
with all files from the /po directory ( but fr.po ) removed, but configure
failed with:
  checking for msgfmt... /usr/bin/msgfmt
  checking for gmsgfmt... /usr/bin/msgfmt
  checking for xgettext... /usr/bin/xgettext
  checking for msgmerge... /usr/bin/msgmerge
  configure: creating ./config.status
  config.status: creating Makefile
  config.status: error: cannot find input file: po/Makefile.in.in
I've also tried builds after adding this file but independent of the presence of
BR:gettext they fail with
  Making all in po
  make[2]: Entering directory `/builddir/build/BUILD/gpar2-0.3/po'
  make[2]: *** No rule to make target `all'.  Stop.
  make[2]: Leaving directory `/builddir/build/BUILD/gpar2-0.3/po'
  make[1]: *** [all-recursive] Error 1
  make[1]: Leaving directory `/builddir/build/BUILD/gpar2-0.3'
  make: *** [all] Error 2
  error: Bad exit status from /var/tmp/rpm-tmp.45363 (%build)



Both my configure-foo and my po-management skills are rather weak so I do not
feel like digging deeper.
However this makes me a bit uneasy because in this moment I really do not know
what would be the proper solution. As far as I see, we have the following
options, listed from ugliest to preferred :
1) Patch configure to drop the fr.po completely.
2) Leave it as it is. Unfortunately I think that this approach violates
http://fedoraproject.org/wiki/Packaging/Guidelines#head-17396a3b06ec849a7c0c6fc3243673b17e5fed90
"For several reasons, a package should not include or build against a local copy
of a library that exists on a system. The package should be patched to use the
system libraries." However in this case the culprit is not a library but an
executable. Does the  above guideline still apply ? In order to respect the
meaning (and not the letter), I would say "yes, it still applies" but I am more
then willing to stand corrected if I am wrong.
3) Patch configure to really use the system wide gettext instead of the private
copy.


Comment 7 manuel wolfshant 2007-12-29 16:21:32 EST
s/food/good/ :)

and yes, I am hungry :))
Comment 8 Adel Gadllah 2007-12-29 20:19:24 EST
It turned out that it does not ship precompiled gettext binarys (could not find
any), but pregenerated pot and gmo files that it uses. I fixed it by removing
the files in %pre and forcing it to recreate them using system gettext (what it
does now).
New SRPM/SPEC: 
http://tgmweb.at/gadllah/gpar2.spec
http://tgmweb.at/gadllah/gpar2-0.3-4.fc8.src.rpm
Comment 9 manuel wolfshant 2007-12-29 21:22:00 EST
Package APPROVED
Comment 10 Adel Gadllah 2007-12-30 05:55:08 EST
(In reply to comment #9)
> Package APPROVED

thx for the review!
-------------------
New Package CVS Request
=======================
Package Name: gpar2
Short Description: GUI for verifying and repairing PAR and PAR2 recovery sets
Owners: drago01
Branches: F-7 F-8
Cvsextras Commits: yes
Comment 11 Kevin Fenzi 2007-12-30 13:00:10 EST
cvs done.

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