> The basic problem is that python2.7-config --ldflags includes "-lpython2.7"
> but no "-L" to say where to find it. On most platforms, a suitable "-L" is
> included.
I don't know anything about that area, but your "most platforms" seems
optimistic.
NetBSD 7.1 (GENERIC.201703111743Z)
-bash-4.
>> Can we get rid of it if very early in the startup sequence, we force the
>> system time to be at least the build time?
> Ah, you're thinking of this as a way to get us into the right half of the
> next era after a wraparound?
I think it's a double win.
It gets rid of that ugly pivot code.
Suppose we release some code. Assume it is bug free so users are happy.
How long do we expect it to run correctly?
Would we be happy with 67 years from the build date?
Do we know the limitations?
--
These are my opinions. I hate spam.
___
deve
>> In an earlier post, Mark stated that he preferred to keep NetBSD6 support
>> if possible because it's still recent enough to get security fixes. If
>> the same criterion is applied to OSX, then 10.10 and 10.11 should be
>> supported.
>I'm absolutely going to count you as a senior dev. So, you
Fred Wright via devel :
>
> On Thu, 14 Sep 2017, Eric S. Raymond wrote:
>
> > So, did I make an ignorant mistake? Can this fix be rescued? Is
> > someone else better equipped than me for the rescue? (Translation:
> > I'd really love to dump this mess on Fred or Gary.)
>
> The point I was tryi
On Thu, 14 Sep 2017, Hal Murray via devel wrote:
> > All the fuss over long doubles has distracted folks from a more legitimate
> > issue with NetBSD 6.1.5, which is that python-config returns a nonworking
> > build setup for the C extension. But a workaround should be possible, and
> > it's onl
On Thu, 14 Sep 2017, Eric S. Raymond wrote:
> So, did I make an ignorant mistake? Can this fix be rescued? Is
> someone else better equipped than me for the rescue? (Translation:
> I'd really love to dump this mess on Fred or Gary.)
The point I was trying to make is that C doesn't promise tha
Yo Eric!
On Thu, 14 Sep 2017 21:26:46 -0400
"Eric S. Raymond via devel" wrote:
> Fred Wright via devel :
> > IMO, if a proper cost-benefit analysis of the use of long doubles
> > in the NTP context were conducted, it would result in a resounding
> > thumbs down.
> Best to avoid any doubt
Gary E. Miller via devel :
> Yo Hal!
>
> On Thu, 14 Sep 2017 16:36:49 -0700
> Hal Murray via devel wrote:
>
> > Can we get rid of it if very early in the startup sequence, we force
> > the system time to be at least the build time?
> >
> > That is, if current time is less than build time, set t
Hal Murray via devel :
>
> Can we get rid of it if very early in the startup sequence, we force the
> system time to be at least the build time?
>
> That is, if current time is less than build time, set the time to build time.
> (no network involved)
Ah, you're thinking of this as a way to ge
Fred Wright via devel :
> IMO, if a proper cost-benefit analysis of the use of long doubles in the
> NTP context were conducted, it would result in a resounding thumbs down.
Thank you, Fred. I found your contribution measured and valuable even
though I'm not certain I understood all of the issues
Yo Hal!
On Thu, 14 Sep 2017 16:36:49 -0700
Hal Murray via devel wrote:
> Can we get rid of it if very early in the startup sequence, we force
> the system time to be at least the build time?
>
> That is, if current time is less than build time, set the time to
> build time. (no network involved
Can we get rid of it if very early in the startup sequence, we force the
system time to be at least the build time?
That is, if current time is less than build time, set the time to build time.
(no network involved)
--
These are my opinions. I hate spam.
Yo Hal!
On Thu, 14 Sep 2017 16:13:43 -0700
Hal Murray via devel wrote:
> > All the fuss over long doubles has distracted folks from a more
> > legitimate issue with NetBSD 6.1.5, which is that python-config
> > returns a nonworking build setup for the C extension. But a
> > workaround should be
> All the fuss over long doubles has distracted folks from a more legitimate
> issue with NetBSD 6.1.5, which is that python-config returns a nonworking
> build setup for the C extension. But a workaround should be possible, and
> it's only in the build procedure, not the code.
Could you please
On Wed, 13 Sep 2017, Hal Murray via devel wrote:
> I think the whole doubletime_t was a wild goose chase.
>
> The claimed reason was precision. A double has 53 bits. We are interrested
> in adjustments, not absolute values. If we are taking a huge adjustment (31
> bits), that still leaves 20 b
Gary E. Miller via devel :
> Yo Mark!
>
> On Thu, 14 Sep 2017 18:55:18 +
> Mark Atwood wrote:
>
> > Fair enough. We should still feed a bug report to NetBSD6, maybe one
> > of their FP guys will patch it in. And we drop NetBSD6 now, because
> > of that lack.
>
> Done. Awaiting the issue
Mark Atwood :
> Fair enough. We should still feed a bug report to NetBSD6, maybe one of
> their FP guys will patch it in. And we drop NetBSD6 now, because of that
> lack.
Checking...Matt already did the NetBSD 6 drop.
Any volunteer to file the NetBSD bug? I don't know their procedures.
--
Yo All!
> Done. Awaiting the issue number.
Just in:
Thank you very much for your problem report.
It has the internal identification `lib/52541'.
The individual assigned to look at your
report is: lib-bug-people.
>Category: lib
>Responsible:lib-bug-people
Yo Mark!
On Thu, 14 Sep 2017 18:55:18 +
Mark Atwood wrote:
> Fair enough. We should still feed a bug report to NetBSD6, maybe one
> of their FP guys will patch it in. And we drop NetBSD6 now, because
> of that lack.
Done. Awaiting the issue number.
RGDS
GARY
---
Fair enough. We should still feed a bug report to NetBSD6, maybe one of
their FP guys will patch it in. And we drop NetBSD6 now, because of that
lack.
..m
On Wed, Sep 13, 2017 at 5:52 PM Eric S. Raymond via devel
wrote:
> Gary E. Miller via devel :
> > Yo Mark!
> >
> > On Wed, 13 Sep 2017 23:
21 matches
Mail list logo
