gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] ✘timestamp_t is dead. Long live timespec_t


From: Greg Troxel
Subject: Re: [gpsd-dev] ✘timestamp_t is dead. Long live timespec_t
Date: Fri, 20 Sep 2019 21:23:55 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

> On Fri, 20 Sep 2019 09:29:27 -0400
> Greg Troxel <address@hidden> wrote:
>
>> But, I still don't see how timeval vs timespec is different.  Both use
>> time_t, which either is or isn't big enough on any particular system.
>
> timeval is in micro-seconds.  timespec is in nano seconds.
>
> It is easy to run gpsd and ntpd to keep time to under a micro-second, so
> timeval is not good enough.

Sure, I get that, and thus I concur that it's obvious that switching to
timespec everywhere is a good thing.  I just don't see how timespec has any
different proprerties than timeval about whether things work in Y2038.

>> I have been having more and more scons issues globally because pkgsrc
>> can build either 2.7 or 3.7 scons, but they both install "scons" so
>> they conflict,
>
> Gentoo does not have the problem.  So I have no idea what that could be.

How does gentoo install two versions of scons, one using 2.7 and one
using 3.7, that are both called scons, and arrange for programs that use
scons to call the right one?  I'm actually serious about the question,
since the question is how to manage the complexity with reasonable pain,
and if there's a nice answer I would be inclined to steal it.  So far I
can only think of renaming scons to scons2.7 and scons3.7 and patching
programs that use scons, or adding /usr/pkg/scons3.7/bin/scons and then
hacking the path based on dependencies.

>> Is gpsd truly agnostic, and is it believed that using 3.7 is 100% ok?
>
> Works for me.  It test 2.7, 3.6 and 3.7 daily.  I'm sure other version
> are also tested frequently.

I now believe all my troubles are due to 1) scons broken caching and 2)
the change to no longer respect PYTHON which I didn't realize, and have
now documented the workaround for.

>> I don't have a binary "python"
>
> That would be in violation of PEP 394.  Complain to your distro.

I should complain to python because the PEP is wrong.  In all
seriousness, opinions differ here.  Not going to be a useful discussion
:-)

Regardless, even if "python" points to python3.7, it should be possible
to build gspd with python2.7, and vice versa.  In each of those cases,
it has to decline to use the bare python.  It is pretty clear this is
broken now, at least for regression tests.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]