Simplify gpsd ebuild and use the latest available version.

Simplify gpsd ebuild and use the latest available version.

This change modifies gpsd ebuild inherited from gentoo to
match the ChromeOS environment. The link is being renamed
from gpsd-2.38-r1.ebuild to gpsd-2.95-r2.ebuild to ensure
that the latest available version is downloaded.

All various GPS sensor protocols compiled in by default are
being disabled, the only protocol left in is "Generic NMEA"
which is what the Mario hardware complies with.

The ebuild src_unpack() function is modifying the setup.py
script to eliminate the run time python dependency.

The startup file gpsd.conf is modified to comply with the
upstart init daemon requirements and to wait for the GPS
device to be created and to enable the GPS before starting
gpsd.

Change-Id: Ie946c850ac7df14a92f6838e65aa7e05ec4119b4

BUG=chromium-os:467
TEST=manual

1. build and install the new image
2. reboot the ChromeOS device
3. being close to open sky run `cgps' from the command line
4. observe dynamic output showing current GPS satellite
   data and results of the fix. (the data should be flowing
   resulting in constant table updates, at least four
   satellites should be visible and the fix should be
   acquired within a few minutes or much less depending on
   previous GPS device activity.

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=3bd687b

[vb, 2011-01-07 00:35:54]

David, guys, please have a look.

This is the first cut, admittedly rough around the edges, but it does the trick,
you can get GPS data from gpsd, so
the app side testing could start.

A few things which need to be sorted out are:

- enable support for plugin devices

- provide GPS management (on/off) hooks. It can be
  controlled through direct writes to /dev/ttyUSB2, but
  fancier ways of doing it can be provided (dbus interface
  addition as demonstrated by rochberg)

- gobi SDK keeps pumping NMEA output flooding
  /var/log/messages - this should be stopped.

- time of acquiring fix should be shortened (GPS vendor SDK
  has some code for that which has not been 
  incorporated/enabled yet)

- we might want to rename the actual ebuild instead of
  creating a softlink with a different number

I am sure there will be more issues, but I would rather get
this going early.

[rochberg, 2011-01-07 18:45:24]

I'm fine with the gpsd changes modulo my comments, but I really don't know
enough portage best practices to OK this CL

http://codereview.chromium.org/6025011/diff/24002/profiles/targets/chromeos/p...
File profiles/targets/chromeos/package.keywords (right):

http://codereview.chromium.org/6025011/diff/24002/profiles/targets/chromeos/p...
profiles/targets/chromeos/package.keywords:51: =sci-geosciences/gpsd-2.95-r2  
x86 arm
I don't understand where this file fits into our builds, but it seems awfully
brittle to encode this down to the -r.

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
File sci-geosciences/gpsd/files/gpsd.conf (right):

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
sci-geosciences/gpsd/files/gpsd.conf:11: GPSD_LOG='/tmp/gpsd.log'
If you put this in /var/log, then the log-capture scripts will pick it up.

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
sci-geosciences/gpsd/files/gpsd.conf:20: if [ "${retry}" = "15" ]; then
20 seconds?

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
File sci-geosciences/gpsd/gpsd-2.38.ebuild (left):

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
sci-geosciences/gpsd/gpsd-2.38.ebuild:52: -e "s:, gpspacket_sources:,
gpspacket_sources, libraries=['m']:g" \
Why don't we need to do this?  Did upstream gpsd fix it?

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
sci-geosciences/gpsd/gpsd-2.38.ebuild:121: keepdir /var/run/usb # needed for
REMOVER
Comment that we've taken out all the hotplug/udev stuff for now?

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
File sci-geosciences/gpsd/gpsd-2.38.ebuild (right):

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
sci-geosciences/gpsd/gpsd-2.38.ebuild:14: KEYWORDS="~amd64 ~arm x86"
It seems like we should somehow differentiate ourselves from the portage ebuild
since we've ripped so much of it out.

At the very least, we should add a comment explaining that we've simplified a
bunch.

[vb, 2011-01-07 21:39:11]

While it's being rebuilt for retesting, I will try to get some build guy to
bless it too.

http://codereview.chromium.org/6025011/diff/24002/profiles/targets/chromeos/p...
File profiles/targets/chromeos/package.keywords (right):

http://codereview.chromium.org/6025011/diff/24002/profiles/targets/chromeos/p...
profiles/targets/chromeos/package.keywords:51: =sci-geosciences/gpsd-2.95-r2  
x86 arm
On 2011/01/07 18:45:24, rochberg wrote:
> I don't understand where this file fits into our builds, but it seems awfully
> brittle to encode this down to the -r.  

good point, dropped the -rXXX part

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
File sci-geosciences/gpsd/files/gpsd.conf (right):

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
sci-geosciences/gpsd/files/gpsd.conf:11: GPSD_LOG='/tmp/gpsd.log'
On 2011/01/07 18:45:24, rochberg wrote:
> If you put this in /var/log, then the log-capture scripts will pick it up.

The only thing which goes into this file are errors reported when the startup
script is running (if any), this is more a means of debugging in case something
changes than a good source of day-to-day debug information, I think /tmp is a
better place for it.

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
sci-geosciences/gpsd/files/gpsd.conf:20: if [ "${retry}" = "15" ]; then
On 2011/01/07 18:45:24, rochberg wrote:
> 20 seconds?

Done.

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
File sci-geosciences/gpsd/gpsd-2.38.ebuild (left):

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
sci-geosciences/gpsd/gpsd-2.38.ebuild:52: -e "s:, gpspacket_sources:,
gpspacket_sources, libraries=['m']:g" \
On 2011/01/07 18:45:24, rochberg wrote:
> Why don't we need to do this?  Did upstream gpsd fix it?

I guess so - there is no compilation/linking errors anymore.

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
sci-geosciences/gpsd/gpsd-2.38.ebuild:121: keepdir /var/run/usb # needed for
REMOVER
On 2011/01/07 18:45:24, rochberg wrote:
> Comment that we've taken out all the hotplug/udev stuff for now?

Done.

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
File sci-geosciences/gpsd/gpsd-2.38.ebuild (right):

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/gpsd-2...
sci-geosciences/gpsd/gpsd-2.38.ebuild:14: KEYWORDS="~amd64 ~arm x86"
On 2011/01/07 18:45:24, rochberg wrote:
> It seems like we should somehow differentiate ourselves from the portage
ebuild
> since we've ripped so much of it out.
> 
> At the very least, we should add a comment explaining that we've simplified a
> bunch.

Done.

[anush, 2011-01-08 00:14:31]

LGTM w/nit. 

You can remove the symlink. The symlinks are usually dependency only ebuild
(like hard-host-deps) so when we add it we just uprev the symlink. We should
also use the right version of the package. I understand it is actually 2.38 then
the ebuild should be called that.

[vb, 2011-01-11 20:50:09]

On 2011/01/08 00:14:31, anush wrote:
> LGTM w/nit. 
> 
> You can remove the symlink. The symlinks are usually dependency only ebuild
> (like hard-host-deps) so when we add it we just uprev the symlink. We should
> also use the right version of the package. I understand it is actually 2.38
then
> the ebuild should be called that.

Ok, I removed the softlink and renamed the ebuild to match the latest gpsd code
version.

David, please look again.

[rochberg, 2011-01-12 00:44:53]

I think we should consider naming the ebuild differently because we've changed
it so much, but that can be another CL

LGTM, but please consider the logger change

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
File sci-geosciences/gpsd/files/gpsd.conf (right):

http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
sci-geosciences/gpsd/files/gpsd.conf:11: GPSD_LOG='/tmp/gpsd.log'
On 2011/01/07 21:39:11, vb wrote:
> On 2011/01/07 18:45:24, rochberg wrote:
> > If you put this in /var/log, then the log-capture scripts will pick it up.
> 
> The only thing which goes into this file are errors reported when the startup
> script is running (if any), this is more a means of debugging in case
something
> changes than a good source of day-to-day debug information, I think /tmp is a
> better place for it.

Ahhh--I understand.   Please consider using logger instead, but if that doesn't
make sense, that's fine

[vb, 2011-01-12 01:00:04]

On 2011/01/12 00:44:53, rochberg wrote:
> I think we should consider naming the ebuild differently because we've changed
> it so much, but that can be another CL
>

It kind of has to be called gpsd-2.95, as the name of the source
archive is derived from ebuild file name.

Maybe portage allows to override this default association, but I
wouldn't worry too much, especially since we are not planning to push
this back to gentoo.

> LGTM, but please consider the logger change
>

I am kind of reluctant to do it for yet another reason: if the init
script does not run due to any problem, there would be no /tmp/gpsd.log file
created, which gives a clear indication that the 
init script did not run. If the file is kept in /var - it becomes more
difficult to tell if the contents of the file are relevant to the most
recent startup.

I'll leave it as is for now, I can see more changes to this file
coming soon, we can revisit this issue later.


>
http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
> File sci-geosciences/gpsd/files/gpsd.conf (right):
> 
>
http://codereview.chromium.org/6025011/diff/24002/sci-geosciences/gpsd/files/...
> sci-geosciences/gpsd/files/gpsd.conf:11: GPSD_LOG='/tmp/gpsd.log'
> On 2011/01/07 21:39:11, vb wrote:
> > On 2011/01/07 18:45:24, rochberg wrote:
> > > If you put this in /var/log, then the log-capture scripts will pick it up.
> > 
> > The only thing which goes into this file are errors reported when the
startup
> > script is running (if any), this is more a means of debugging in case
> something
> > changes than a good source of day-to-day debug information, I think /tmp is
a
> > better place for it.
> 
> Ahhh--I understand.   Please consider using logger instead, but if that
doesn't
> make sense, that's fine