This is just a simple perl module so this should be easy, but this package
seems to be very old and has some interesting things in it.

First off, I'm sure it predates any kind of naming guidelines, but it really
should be called perl-Newt.

rpmlint says:
W: newt-perl incoherent-version-in-changelog 1.08-12 1.08-13
   This just looks like a typo in the last changelog entry.

E: newt-perl zero-length
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Newt/Newt.bs
   The usual Perl specfile template deletes these zero-length droppings with
   find $RPM_BUILD_ROOT -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'

newt-devel is listed twice in BuildRequires.

The license should be "GPL or Artistic", as it is released under the same
terms as Perl.

Nobody I asked could come up with any reason why brp-compress would have to be
run manually in %install.

This is an arch-specific package so generally you need to pass
OPTIMIZE="$RPM_OPT_FLAGS" in %build.  However, if you don't it just uses the
flags that Perl was built with, which are actually OK.

The permissions come out a bit odd, with no owner write bit set.  These are
generally fixed up with a quick chmod.  I also didn't see a reason for the
"fix Newt.so perms" bit as those permissions are set just fine without any
manuall setting.

I'll attach a patch which fixes these issues.  I've left the issue of the name
along, as I'm not sure it's feasible to fix during the F7 test process.

* source files match upstream:
35e78461b24ea7544d030fe71c82b6f633ea56f9bf0fa924ea61e1497863821f  Newt-1.08.tar.gz
X package should be named perl-Newt.
* specfile is properly named, is cleanly written and uses macros consistently.
* build root is OK
  (Actually I'm assuming that the latest packaging committee output will be
  ratified on Thursday; I'll correct this review if it isn't.)
X license field matches the actual license.
* license is open source-compatible.
* license text not included upstream.
* latest version is being packaged.
* BuildRequires are proper (newt-devel is listed twice, but that doesn't
  really hurt)
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks OK.
X rpmlint has valid complaints.
* final provides and requires are sane:
  newt-perl-1.08-13.x86_64.rpm
   Newt.so()(64bit)
   perl(Newt) = 1.8
   newt-perl = 1.08-13
  =
   libnewt.so.0.52()(64bit)
   libnewt.so.0.52(NEWT_0.52)(64bit)
   perl(:MODULE_COMPAT_5.8.8)
   perl(AutoLoader)
   perl(Carp)
   perl(DynaLoader)
   perl(Exporter)
   perl(strict)
   perl(vars)

* %check is not present; test suite is present but interactive.
* no shared libraries are added to the regular linker search paths.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
X file permissions are a bit odd.
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers.
* no pkgconfig files.
* no static libraries.

Created attachment 148989 [details]
Suggested specfile patch fixing several issues.

Thanks a lot for the review and patch!

I've applied this in -14.  I'm not sure now is a good time to rename the
package, but I've changed crypto-utils (the only package which uses newt-perl)
to use Require/BuildRequire: perl(Newt) to facilitate that.

(In reply to comment #3)
> Thanks a lot for the review and patch!
> 
> I've applied this in -14.  I'm not sure now is a good time to rename the
> package, but I've changed crypto-utils (the only package which uses newt-perl)
> to use Require/BuildRequire: perl(Newt) to facilitate that.
> 

So long as you coordinate with those that need newt-perl the rename now should
be fine.  You'll be doing an obsoletes/provides though right?

Jesse: sure; I'm happy to rename this now if it doesn't create more work for
you.  What's the process for a package rename?

(In reply to comment #5)
> Jesse: sure; I'm happy to rename this now if it doesn't create more work for
> you.  What's the process for a package rename?

Depends on if you want to keep history or not.  If you don't, we can import the
new srpm named perl-newt as a new package, and I'll block the old one from the
buildsystem, adding hte new one.  If you want to keep cvs history, this might
get more difficult, but not impossible.

I don't care about preserving CVS across the rename, no.  New package at:

~jorton/perl-Newt-1.08-15.src.rpm

Any chance you could give a full hostname or put that in a publicly accessible
place?  If it's in your home directory, there's a rather slim chance I can get
to it.

Sorry, sure - http://people.redhat.com/jorton/perl-Newt-1.08-15.src.rpm

This fails to build for me on rawhide due to the perl-devel split; I added BR:
perl-devel and all is well.

The issues I had are fixed:
  Package name is good.
  License is OK.
  rpmlint is quiet.
  Permissions are fixed.

Looks good to me, other than that perl-devel thing.  I believe that's here to
stay, but the tweak here is easy.

APPROVED

*** Bug 216610 has been marked as a duplicate of this bug. ***

Did this ever get in?

Nope. I guess we need to treat this as a new package?  Here's the SRPM with the
perl-devel BR added:

http://people.redhat.com/jorton/perl-Newt-1.08-16.src.rpm

New Package CVS Request
=======================
Package Name: perl-Newt
Short Description: 
Owners: jorton
Branches: devel
InitialCC: 

Not sure if you needed an F-7 branch for this or not, I assumed not.

Also, please remember to fill in the Short Description field on CVS new package
requests.

CVS done.

Can we close this now?

Yes we can!