Bug 225847 - Merge Review: gnupg
Merge Review: gnupg
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gnupg (Show other bugs)
23
All Linux
medium Severity medium
: ---
: ---
Assigned To: Todd Zullinger
Fedora Package Reviews List
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 13:56 EST by Nobody's working on this, feel free to take it
Modified: 2016-12-20 06:57 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 06:57:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch correcting small issues mentioned above (4.64 KB, patch)
2007-02-03 10:37 EST, Todd Zullinger
no flags Details | Diff

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 13:56:12 EST
Fedora Merge Review: gnupg

http://cvs.fedora.redhat.com/viewcvs/devel/gnupg/
Initial Owner: nalin@redhat.com
Comment 1 Todd Zullinger 2007-02-03 10:32:43 EST
Hi Nalin.  Here's a review for gnupg.

MUST items verified

* Adheres to naming guidelines
* Specfile name matches package name
* Meets packaging guidelines (see below for comment on %{_libexecdir} usage
* License meets open-source requirements
* License included in %doc
* License field matches the upstream license
* Specfile is in American English
* Specfile is legible
* Source matches upstream (sha1: 9cbbef5c94f793867ff3ae4941816962311a0563)
* Builds, installs, and works (tested on FC6, i386)
* Owns directories that it creates
* Does not own files or directories of other packages
* File list has no duplicates
* File perms are sane
* Specfile includes %clean section
* Macros used consistently
* Package contains code or permissible content


SHOULD items verified

* Builds in mock against fedora-{5,6}-i386-core targets
* Package functions correctly (tested on FC6, i386)


NEEDSWORK items

* rpmlint produces several warnings and errors on the srpm

$ rpmlint gnupg-1.4.6-3.src.rpm
W: gnupg summary-ended-with-dot A GNU utility for secure communication and data
storage.
E: gnupg tag-not-utf8 %changelog
E: gnupg non-utf8-spec-file gnupg.spec
W: gnupg buildprereq-use autoconf, automake, bzip2-devel, expect, ncurses-devel
W: gnupg buildprereq-use openldap-devel, readline-devel, zlib-devel, gettext-devel
W: gnupg buildprereq-use curl-devel
W: gnupg buildprereq-use libusb-devel
W: gnupg unversioned-explicit-provides gpg
W: gnupg unversioned-explicit-provides openpgp
W: gnupg prereq-use /sbin/install-info
W: gnupg make-check-outside-check-section make check
E: gnupg use-of-RPM_SOURCE_DIR
W: gnupg mixed-use-of-spaces-and-tabs (spaces: line 73, tab: line 50)

All except the unversioned-explicit-provides on the virtual gpg and openpgp
packages should be corrected.

The binary rpm produces one warning:

$ rpmlint gnupg-1.4.6-4.fc6-results/gnupg-1.4.6-4.fc6.i386.rpm 
W: gnupg file-not-utf8 /usr/share/man/man1/gpg.ru.1.gz

I don't know Russian so I couldn't verify if iconv would properly converted the
man page so I left it alone.

* Scriplets are sane

The scriptlets to install info pages could be simplified somewhat and made more
consistent with the examples in Packaging/ScriptletSnippets


Comments/Questions/Notes

There are a number of unneeded configure flags to enable zlib, bzip, readline,
and curl.  These are all enabled by default in the current gnupg so they can be
removed.

Why is %{_libdir} used for %{_libexecdir}?  Packaging/Guidelines allow the use
of this dir and it is what upstream does by default.  %{_libdir}/gnupg is used
for extensions, though none are currently shipped with this package (or by any
others in Fedora AFAIK).

The CFLAGS are set explicitly to prevent the binaries from having text
relocations, as per BZ#145836 (in case anyone wonders about that).

Another very a minor point, the preferred value for the BuildRoot tag is
%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
This is not a blocker.

I was unable to build this in mock for the development target due to expect
having a broken dep on libtcl8.4.so at the moment.

NEEDSWORK
Comment 2 Todd Zullinger 2007-02-03 10:37:04 EST
Created attachment 147274 [details]
patch correcting small issues mentioned above

Here's a patch to correct the (relatively minor) issues mentioned above.  Feel
free to ditch my changelog entry if you use any parts of the patch.  I'll take
the blame for things I break but I don't care about getting credit. :)
Comment 3 Nalin Dahyabhai 2009-02-19 15:32:26 EST
(In reply to comment #1)
> Hi Nalin.  Here's a review for gnupg.

Thanks for that, sorry for the delay.

> NEEDSWORK items
> 
> * rpmlint produces several warnings and errors on the srpm

Fixed up at various times by various people... looks pretty clean now.

> The binary rpm produces one warning:
> 
> $ rpmlint gnupg-1.4.6-4.fc6-results/gnupg-1.4.6-4.fc6.i386.rpm 
> W: gnupg file-not-utf8 /usr/share/man/man1/gpg.ru.1.gz
> 
> I don't know Russian so I couldn't verify if iconv would properly converted the
> man page so I left it alone.

rpmlint says this needs to be UTF-8, but it's evidently KOI8-RU.  Converting.

> * Scriplets are sane
> 
> The scriptlets to install info pages could be simplified somewhat and made more
> consistent with the examples in Packaging/ScriptletSnippets

The additional checks fix #91641 (error when installed with --excludedocs).  I'd rather just leave it as-is and not have to worry about that.

> Comments/Questions/Notes
> 
> There are a number of unneeded configure flags to enable zlib, bzip, readline,
> and curl.  These are all enabled by default in the current gnupg so they can be
> removed.

Dropped explicit requests for bzip, readline, and curl, but leaving the one for zlib in so that configure won't fall back to the internal copy if something looks "off" about the system one.

> Why is %{_libdir} used for %{_libexecdir}?  Packaging/Guidelines allow the use
> of this dir and it is what upstream does by default.  %{_libdir}/gnupg is used
> for extensions, though none are currently shipped with this package (or by any
> others in Fedora AFAIK).

We used to not allow %{_libexecdir}.  Reverted.

> Another very a minor point, the preferred value for the BuildRoot tag is
> %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> This is not a blocker.

Changed to match at some point.  I think it looks pretty good now.
Comment 4 Tomas Mraz 2010-01-12 09:37:43 EST
gnupg is dead.package in rawhide now.
Comment 5 Parag AN(पराग) 2012-06-15 12:27:10 EDT
This bug just popped out when I searched for packages under review but looks like this package is dead already.

Dropping the flag fedora-review?
Comment 6 Tomas Mraz 2012-06-15 16:28:54 EDT
Actually it was revived by bcl.
Comment 7 Cole Robinson 2015-02-11 15:36:52 EST
Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:

  https://fedorahosted.org/fesco/ticket/1269

If you don't know what merge reviews are about, please see:

  https://fedoraproject.org/wiki/Merge_Reviews

How to handle this bug is left to the discretion of the package maintainer.
Comment 8 Parag AN(पराग) 2015-06-10 01:08:22 EDT
Based on above there is no need to review this package anymore.
Comment 9 Jan Kurik 2015-07-15 11:25:49 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 10 Fedora End Of Life 2016-11-24 05:19:23 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 11 Fedora End Of Life 2016-12-20 06:57:29 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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