Bug 510822

Builds fine; rpmlint says: 
  maloc.x86_64: W: no-documentation
  maloc-devel.x86_64: W: no-documentation
which are OK, and

  maloc.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libmaloc.so.1.0.0
   /lib64/libncurses.so.5
Which is odd; why is this linked against ncurses when it doesn't call ncurses?  I guess this has something to do with readline.  I wouldn't say it's a problem because libncurses is going to come in either way.

Full review forthcoming.

(In reply to comment #1)
> 
>   maloc.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libmaloc.so.1.0.0
>    /lib64/libncurses.so.5
> Which is odd; why is this linked against ncurses when it doesn't call ncurses? 
> I guess this has something to do with readline.  I wouldn't say it's a problem
> because libncurses is going to come in either way.
> 

Noticed that - the configure.ac specifically checks for ncurses, I don't know why.  I'll mention it to upstream.

I'm a bit confused about the versioning.  Is the "-1" in the tarball indicative of some sub-version thing?  Will they release 0.2-2 in the future?  What would you call this package in that case?  Upstream also produces RPMs and seems to use the dashed portion of the version as their Release: (or perhaps that's just coincidental), but it should be obvious that we can't do that.

The blank line at the start of %description does make it into the final package and should probably be removed.

Did you intend not to build and package the documentation?  It seems like that would be a good idea, but I haven't checked that the documentation is actually useful.

Why does this require pkgconfig?  I don't see any .pc files in the package.

* source files match upstream.  sha256sum:        
   9b29c4b6401adf20ce1ab3c47fe71066ca7952eb10db4b1e6b1440973f616cda
   maloc-0.2-1.tar.gz
? name is OK; not sure about package versioning.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.                                                              
* description is OK.                                                          
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text not included upstream.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
? final provides and requires:
  maloc-0.2-1.fc12.x86_64.rpm
   libmaloc.so.1()(64bit)
   maloc = 0.2-1.fc12
   maloc(x86-64) = 0.2-1.fc12
  =
   /sbin/ldconfig
   libmaloc.so.1()(64bit)
   libncurses.so.5()(64bit)
   libreadline.so.5()(64bit)

  maloc-devel-0.2-1.fc12.x86_64.rpm
   maloc-devel = 0.2-1.fc12
   maloc-devel(x86-64) = 0.2-1.fc12
  =
   libmaloc.so.1()(64bit)
   maloc = 0.2-1.fc12
?  pkgconfig

* %check is present; no test suite upstream.
* shared libraries are installed:
   ldconfig called properly.
   unversioned .so links are in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* no generically named files.
* scriptlets are OK (ldconfig).
* code, not content.
* headers are in the -devel package.
* no pkgconfig files (but maybe there should be?)
* no static libraries.
* no libtool .la files.

The package review process needs reviewers!  If you haven't done any package
reviews recently, please consider doing one.

(In reply to comment #3)
> I'm a bit confused about the versioning.  Is the "-1" in the tarball 
> indicative of some sub-version thing?  Will they release 0.2-2 in the 
> future?  What would you call this package in that case?  Upstream also 
> produces RPMs and seems to use the dashed portion of the version as their 
> Release: (or perhaps that's just coincidental), but it should be obvious that 
> we can't do that.
> 

I'm not sure what that indicates, and its entirely reasonable to assume a "-2" version will be made at some point. Is it possible/OK to just transmogrify "0.2-1" into "0.2.1"? Perhaps its best to ask upstream WTF that number represents?

> The blank line at the start of %description does make it into the final package
> and should probably be removed.
> 

done.

> Did you intend not to build and package the documentation?  It seems like that
> would be a good idea, but I haven't checked that the documentation is actually
> useful.
> 

Oh, yeah - i kind of whipped this up in a jif so I could test the apbs builds I was doing - I'll add that in.

> Why does this require pkgconfig?  I don't see any .pc files in the package.
> 

Oops - removed.

> 
> The package review process needs reviewers!  If you haven't done any package
> reviews recently, please consider doing one.  

When I get enough free time, I'll jump in!  :)

Since a dash isn't legal in a version, I would transform it into an underscore.  You never know; they might actually release 0.2.1-1 in the future.  (Although unfortunately 0.2_2 sorts newer than 0.2.1_1, so if they did that you would have to resort to using Epoch: to get things to sort properly.)

Honestly the best thing to do is ask them.

2 emails, no reply on the version numbering.  :(

If you don't hear from upstream, there are a couple of possibilities.  If they won't reply to a simple question like that, how are they going to reply to bug reports?  Is it worth packaging software with an absent upstream?  If you're still sure you want to package it, you could just make a guess.  Honestly I'd just drop the bit after the dash and later add it into the version somehow if you get a response from upstream that indicates it's meaningful.  You can always rely on Epoch: to force an ordering if you need to.

(In reply to comment #7)
> If you don't hear from upstream, there are a couple of possibilities.  If they
> won't reply to a simple question like that, how are they going to reply to bug
> reports?  Is it worth packaging software with an absent upstream?

They've been responsive to other issues, so I'm assuming this issue is just below their radar.

Spec URL: http://www.stanford.edu/~fenn/packs/maloc.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/maloc-0.2-2.fc10.src.rpm

Unfortunately that package doesn't build for me.

+ make -C doc/doxygen
make: Entering directory `/builddir/build/BUILD/maloc/doc/doxygen'
doxygen maloc.dox
make: execvp: doxygen: Permission denied

That's kind of odd, but the package doesn't seem to have any build dependency on doxygen, so most likely it's simply not there.

(In reply to comment #9)
> Unfortunately that package doesn't build for me.
> 
> + make -C doc/doxygen
> make: Entering directory `/builddir/build/BUILD/maloc/doc/doxygen'
> doxygen maloc.dox
> make: execvp: doxygen: Permission denied
> 
> That's kind of odd, but the package doesn't seem to have any build dependency
> on doxygen, so most likely it's simply not there.  

Added doxygen to the buildreq:

Spec URL: http://www.stanford.edu/~fenn/packs/maloc.spec
SRPM URL: http://www.stanford.edu/~fenn/packs/maloc-0.2-3.fc10.src.rpm

OK, builds fine, rpmlint is as previously discussed above and the versioning loooks good to me.

APPROVED

New Package CVS Request
=======================
Package Name: maloc
Short Description: Minimal Abstraction Layer for Object-oriented C/C++ programs
Owners: timfenn
Branches: F-11 EL-5
InitialCC: timfenn

CVS done

builds for EL-5, F-11 and devel done.

Is there any reason for this ticket to remain open?

no, should be closed.

Package Change Request
======================
Package Name: maloc
New Branches: epel7
Owners: timfenn
InitialCC: timfenn

Git done (by process-git-requests).