Bug 426922
Summary: | Review Request: gpar2 - GUI for verifying and repairing PAR and PAR2 recovery sets | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adel Gadllah <adel.gadllah> |
Component: | Package Review | Assignee: | manuel wolfshant <manuel.wolfshant> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | fedora-package-review, notting |
Target Milestone: | --- | Flags: | manuel.wolfshant:
fedora-review+
kevin: fedora-cvs+ |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-12-30 18:53:46 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: | 426919 | ||
Bug Blocks: |
Description
Adel Gadllah
2007-12-28 13:16:26 UTC
NOTE: This depends on libpar2 currently under review: https://bugzilla.redhat.com/show_bug.cgi?id=426919 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. Updated srpm and spec: http://tgmweb.at/gadllah/gpar2.spec http://tgmweb.at/gadllah/gpar2-0.3-2.fc8.src.rpm 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. (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 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. s/food/good/ :) and yes, I am hungry :)) 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 Package APPROVED (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 cvs done. |