Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 188090 - Review Request: gpsd
Summary: Review Request: gpsd
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kevin Fenzi
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-04-05 22:33 UTC by Matthew Truch
Modified: 2014-08-11 12:19 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-04-13 22:42:14 UTC
Type: ---
Embargoed:
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Matthew Truch 2006-04-05 22:33:30 UTC
Spec Name or Url: http://matt.truch.net/fedora/gpsd.spec
SRPM Name or Url: http://matt.truch.net/fedora/gpsd-2.32-1.src.rpm
Description: 
gpsd is a service daemon that mediates access to a GPS sensor
connected to the host computer by serial or USB interface, making its
data on the location/course/velocity of the sensor available to be
queried on TCP port 2947 of the host computer.  With gpsd, multiple
GPS client applications (such as navigational and wardriving software)
can share access to a GPS without contention or loss of data.  Also,
gpsd responds to queries with a format that is substantially easier to
parse than NMEA 0183.

Thanks in advance for the review!

Note, I based the rpm on the spec that comes with gpsd, although I made it conform to fedora-extras requirements as much as possible.
rpmlint complains about: 
E: gpsd-clients only-non-binary-in-usr-lib
And this is due to 'config' files placed in /usr/lib/X11/app-defaults/ as per how the original rpm spec did things.  The programs run fine (using the same defaults) without these files, so perhaps I should not include them?  This is new territory for me, so I thought I'd check first.

Comment 1 Kevin Fenzi 2006-04-09 23:22:38 UTC
A review:

See Below - Rpmlint output.
OK - Package name.
OK - Spec file name matches.
OK - Package guidelines.
OK - Licsense. (BSD)
OK - License field matches in spec.
OK - License included in files
OK - Spec in american english
OK - Spec legible
See below- Md5sum of source from upstream
OK - Compiles and builds on one arch at least.
See below - All required buildrequires included?
OK - Ldconfig in post/postun if including libs.
OK - Owns all directories it creates.
OK - No duplicate files in %files listing.
OK - Permissions on files correct.
OK - Clean section correct.
OK - Macros consistant.
OK - Code not content.
OK - Header files/libs in a devel package.
OK - .so files in devel package.
OK - Devel package requires base package.
OK - No .la files.
OK - .desktop file if a GUI app
OK - Doesn't own any files/dirs that are already owned by others.

Items needing attention:

1. md5sum's of the upstream source don't seem to match:

4bb9b0c1642d36265c807a04da3d6f60  gpsd-2.32.tar.gz
8212ac4b10deb3f69d84b80a8a0d3cfd  gpsd-2.32.tar.gz.1

2. Are you only planning for this to be in devel?
You might consider using a dist tag...
http://fedoraproject.org/wiki/DistTag
For fc4 you would also have to change the X BuildRequires.

3. Consider supressing /usr/lib/libgps.a file with
--disable-static or removing the .a file before packaging.

4. The 'E: gpsd-clients only-non-binary-in-usr-lib' rpmlint
can probibly be ignored. It's good to ship app-defaults files
so people can customize as they like. perhaps file an RFE
against rpmlint to allow this case?

5. I see in the build logs:
xmlto man gps.xml
make[1]: xmlto: Command not found
make[1]: [gps.1] Error 127 (ignored)

Perhaps a 'BuildRequires: xmlto' is needed?

6. You use a python call to determine the python site dir,
should you also have a 'BuildRequires: python'? It's not in the
exceptions list of packages not to list. (Althought it's in
the base build group, so it works)

7. There is also a 'W: gpsd non-conffile-in-etc /etc/hotplug/usb/gpsd.usermap'
from rpmlint. I think thats safe to ignore as well.


Comment 2 Matthew Truch 2006-04-10 05:11:31 UTC
(In reply to comment #1)
> Items needing attention:
> 
> 1. md5sum's of the upstream source don't seem to match:
> 
> 4bb9b0c1642d36265c807a04da3d6f60  gpsd-2.32.tar.gz
> 8212ac4b10deb3f69d84b80a8a0d3cfd  gpsd-2.32.tar.gz.1

This is weird.  I get that they do:

4bb9b0c1642d36265c807a04da3d6f60  gpsd-2.32.tar.gz
4bb9b0c1642d36265c807a04da3d6f60  gpsd-2.32.tar.gz.1

Ohhh, maybe I accidentally used the source from the upstream srpm the first time
around (and perhaps that source tarball doesn't match).  Weird.  

> 2. Are you only planning for this to be in devel?
> You might consider using a dist tag...
> http://fedoraproject.org/wiki/DistTag

I know, and included the dist tag shortly after I submitted this bug report (but
didn't yet post the new srpm as it was the only change).  I use it in the new
srpm as indicated below.

> For fc4 you would also have to change the X BuildRequires.

Right.  Will do if I build for fc4 (as right now I'm not even sure what is
needed).  

> 3. Consider supressing /usr/lib/libgps.a file with
> --disable-static or removing the .a file before packaging.

Done.  

> 4. The 'E: gpsd-clients only-non-binary-in-usr-lib' rpmlint
> can probibly be ignored. It's good to ship app-defaults files
> so people can customize as they like. perhaps file an RFE
> against rpmlint to allow this case?

Ok, ignoring error.

> 5. I see in the build logs:
> xmlto man gps.xml
> make[1]: xmlto: Command not found
> make[1]: [gps.1] Error 127 (ignored)
> 
> Perhaps a 'BuildRequires: xmlto' is needed?

Oops.  My bad.  Fixed.

> 6. You use a python call to determine the python site dir,
> should you also have a 'BuildRequires: python'? It's not in the
> exceptions list of packages not to list. (Althought it's in
> the base build group, so it works)

Also fixed.  

> 7. There is also a 'W: gpsd non-conffile-in-etc /etc/hotplug/usb/gpsd.usermap'
> from rpmlint. I think thats safe to ignore as well.

Also ignoring.  

New spec and srpm:
http://matt.truch.net/fedora/gpsd.spec
http://matt.truch.net/fedora/gpsd-2.32-1.src.rpm

Comment 3 Kevin Fenzi 2006-04-11 23:55:41 UTC
>This is weird.  I get that they do:
>
>4bb9b0c1642d36265c807a04da3d6f60  gpsd-2.32.tar.gz
>4bb9b0c1642d36265c807a04da3d6f60  gpsd-2.32.tar.gz.1
>
>Ohhh, maybe I accidentally used the source from the upstream srpm the firsttime
>around (and perhaps that source tarball doesn't match).  Weird.  

Ok, something must have been odd with my initial download. 
I now get that same md5sum. Downloaded it several places and it all matched. 
Not sure if there was a hiccup on berlios, somewhere in between or what, but it 
looks ok now. 

>> For fc4 you would also have to change the X BuildRequires.
>
>Right.  Will do if I build for fc4 (as right now I'm not even sure what is
>needed).  

ok. Probibly will need xorg-x11-devel there. 

>New spec and srpm:
>http://matt.truch.net/fedora/gpsd.spec
>http://matt.truch.net/fedora/gpsd-2.32-1.src.rpm

You mean http://matt.truch.net/fedora/gpsd-2.32-3.src.rpm, right? 
In any case that seems to be the right one. ;) 

I can't seem to get this to build under mock, but it looks like a dbus-devel
and/or problem with my test machine. It builds fine otherwise. 

All the blockers are fixed, so this package is APPROVED. 

Comment 4 Kevin Fenzi 2006-04-12 03:58:19 UTC
FYI, the mock build problems I was seeing were due to a missing 
BuildRequires: dbus-glib
which is needed for the link in dbus-devel to be working and pointing to the
right library. 

Comment 5 Matthew Truch 2006-04-13 22:42:14 UTC
Built and should be available shortly.

Thanks again for the review.

Comment 6 François Cami 2014-08-11 09:15:39 UTC
Package Change Request
======================
Package Name: gpsd
New Branches: epel7
Owners: fcami

Note:  Miroslav Lichvar stated by email I could maintain the EPEL7 branch.

Comment 7 Gwyn Ciesla 2014-08-11 12:19:59 UTC
Git done (by process-git-requests).


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