Bug 669010

Here is my advice on possible ways to improve the package:

- you should modify the "License" tag to GPLv3 or GPLv3+ (the authors should provide you with further information on whether it's only GPL version 3 or also any later version). Remove Artistic because this is not a Perl module and, as you said, Artistic 1.0 is not allowed in Fedora
- permission of libfap.spec is 0664, this should be changed to 0644

Updates from upstream author about licencing:

>> I'm packaging up libfap into an RPM for Fedora, but I notice all the
>> web pages mention 'copying' under GPL / artistic licence, but can you
>> explicitly mention modification?
> 
> Sure, my mistake. Now it is mentioned.
>
>> also can you say what version of the artistic licence is used
>> (clarified or 2.0) (as v 1.0 isn't acceptable apparently)
>
> My intention is to follow the licensing of the original Perl code, which
> uses v. 1.0. This is now also mentioned.
>
> Many thanks for pointing out those issues and especially packing libfap as
> an RPM! Is it available somewhere on the Internets, so that I could link to
> it?"

and then again:
> Hi again,
>
> On 12.01.2011 10:43:18, Andrew Elwell wrote:
>> also can you say what version of the artistic licence is used
>> (clarified or 2.0) (as v 1.0 isn't acceptable apparently)
>
> I forgot to mention that if the dual licensing model is an issue, drop the
> Artistic License. You can also use more recent version of the GPL if you
> want. The licensing terms allow both actions.
>
> If libfap needs to be modified in order to make an RPM of it, it is totally
> ok with me to release the modifications only under GPLv3 for example. But if
> you make other changes, it would be nice to have them available under the
> original licensing terms, so that they can be migrated back if wanted. But
> that is of course for you to decide.

Upstream released v1.0 on the 17th. Updated spec and srpm available:

Spec URL: http://dl.dropbox.com/u/6594808/Fedora/libfap.spec
SRPM URL: http://dl.dropbox.com/u/6594808/Fedora/libfap-1.0-1.fc14.src.rpm

Mock build OK
...
State Changed: build
INFO: Done(/home/aelwell/rpmbuild/SRPMS/libfap-1.0-1.fc14.src.rpm) Config(default) 1 minutes 8 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-14-x86_64/result

rpmlint output looks OK:
[aelwell@pcitgtelwell libfap]$ rpmlint ~/Dropbox/Public/Fedora/libfap-1.0-1.fc14.src.rpm ~/Dropbox/Public/Fedora/libfap.spec 
1 packages and 1 specfiles checked; 0 errors, 0 warnings.

Builds fine and rpmlint is completely silent.  (But note that it's not sufficient to run rpmlint on the source package; you need to run it on the generated binary packages as well.)

As before, you can dispense with BuildRoot, %clean and the first line of %install if you don't intend to target el4 or el5 with the same spec.

I'm not sure there's much point in mentioning the Perl module in the Summary: or in the %description.  Why not just describe what the package does?  Especially in the %description, there's not much point in referring people to the Perl module when we don't even package it.

I'm pretty sure that the current License: tag is OK.  It's rare to see non-Perl code under that License, but I see no problem with it.  I'm not sure what was up with comment #1, since there's no mention of GPLv3 anywhere.  We do permit code under the Artistic license as long as it's dual-licensed with something acceptable, and we do continue to list Artistic as one of the licenses in that case.

Several documentation files are duplicated between the main and -devel packages.  This needs fixing.

fap.h looks relatively generic, but I did some searching and didn't find anything else it might conflict with, so it seems OK.

* source files match upstream.  sha256sum:
  ae98bee679fd8c5c286796f8382c99781b14b383732de33f781d8e760eebc68f
   libfap-1.0.tar.gz
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
X summary could use work.
X description could use work.
* dist tag is present.
* license field matches the actual license.
* license is open source-compatible.
* license texts included in package.
* latest version is being packaged.
* BuildRequires are proper (none).
* compiler flags are appropriate.
* package builds in mock (rawhide, x86_64).
* package installs properly.
* debuginfo package looks complete.
* rpmlint is silent.
* final provides and requires are sane:
  libfap-1.0-1.fc15.x86_64.rpm
   libfap.so.4()(64bit)  
   libfap = 1.0-1.fc15
   libfap(x86-64) = 1.0-1.fc15
  =
   /sbin/ldconfig  

  libfap-devel-1.0-1.fc15.x86_64.rpm
   libfap-devel = 1.0-1.fc15
   libfap-devel(x86-64) = 1.0-1.fc15
  =
   libfap = 1.0-1.fc15
   libfap.so.4()(64bit)  

* no bundled libraries.
* shared libraries installed:
   ldconfig is called properly.
   unversioned .so files are in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
X several duplicates in %files.
* file permissions are appropriate.
* no generically named files.
* scriptlets are OK (ldconfig).
* code, not content.
* documentation is small, so no -doc subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in the -devel package.
* no static libraries.
* no libtool .la files.

If you look at version 0.9, which was available at the time I made my comment, then you will discover that the package was carrying GPLv3 (file licenses/GPL.txt). This is no longer true with the version 1.0 of the same package, but my comment was made about ten days ago before this new version came out.

Apparently now the license is GPL version 1 or greater. Hopefully they won't change their mind again in the future...

Updated spec and rebuilt. 

Spec URL: http://dl.dropbox.com/u/6594808/Fedora/libfap.spec
SRPM URL: http://dl.dropbox.com/u/6594808/Fedora/libfap-1.0-2.fc14.src.rpm

build cleanly in mock (F14).

libfap-devel now simply contains
$ rpm -qlp ~/rpmbuild/RPMS/x86_64/libfap-devel-1.0-2.fc14.x86_64.rpm 
/usr/include/fap.h
/usr/lib64/libfap.so

I'm leaving in the BuildRoot etc as I'd like it to be available in EPEL5 (and I've just tested it builds OK under mock, subject to building the srpm on F14 with rpmbuild -bs --define _source_filedigest_algorithm=1 libfap.spec(

I've not expanded the acronymn APRS in the Summary as it'll take up too many characters, but have in the Description.

rpmlint now throws a warning on the -devel about no documentation - can I ignore this as the main package (which is a requires: for -devel) pulls it in? (I think this was the reason I originally duplicated those files!)

[aelwell@pcitgtelwell ~]$ rpmlint ~/rpmbuild/RPMS/x86_64/libfap-*1.0-2*
libfap-devel.x86_64: W: no-documentation
3 packages and 0 specfiles checked; 0 errors, 1 warnings.

Yes, it's perfectly OK that rpmlint complain about no-documentation when you don't actually have any documentation.  You shouldn't invent or duplicate some just to quite rpmlint.  Sometimes you can decide that some documentation should go in the -devel package and some in the main package, but that doesn't seem to be the case here.

Generally for summaries (and especially for something like a library that users will rarely install on their own anyway) there's not much in indicating what language the package is written in.  It's certainly not worth arguing over, though.  Just imagine that you installed some application and it pulled in this library.  Does the summary provide enough information for you to make a quick judgment about whether you really want that install to go ahead?

Otherwise this looks OK to me.  However, I just now noticed your message about smoketest.c.  If at all possible it would be nice to get that built so it could be run in a %check section.  Just adding

%check
make check

is sufficient and gives a bunch of useful information.

Anyway, with that, this is about done.  I need to look over your pre-reviews and then I'll push the necessary buttons.

Great, didn't know about make check. Added to spec, and it passed on F14. 
Mock build went OK and ran all the tests sucessfully.

Spec URL: http://dl.dropbox.com/u/6594808/Fedora/libfap.spec
SRPM URL: http://dl.dropbox.com/u/6594808/Fedora/libfap-1.0-3.fc14.src.rpm

Looks great; APPROVED

I've already updated your privileges in the account system; that may take a bit of time to propagate but once it has you'll be able to make an SCM request and set the fedora-cvs flag.  See https://fedoraproject.org/wiki/Package_SCM_admin_requests for more info on that.

New Package SCM Request
=======================
Package Name: libfap
Short Description: Amateur Radio APRS parser
Owners: elwell
Branches: f13 f14 el6
InitialCC: hams-sig

Git done (by process-git-requests).

libfap-1.0-3.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/libfap-1.0-3.fc14

libfap-1.0-3.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/libfap-1.0-3.fc13

libfap-1.0-3.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/libfap-1.0-3.el6

libfap-1.0-3.el6 has been pushed to the Fedora EPEL 6 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update libfap'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/libfap-1.0-3.el6

libfap-1.0-3.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

libfap-1.0-3.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

libfap-1.0-3.fc13 has been pushed to the Fedora 13 stable repository.