Yo Richard!
On Tue, 5 Dec 2017 23:57:37 -0600
Richard Laager via devel wrote:
> [Replying to lots of different people, slightly out-of-order.]
>
> On 12/05/2017 09:52 AM, Eric S. Raymond via devel wrote:
> > I'm not clear why we care about the pip cases.
>
> I agree. If this matters, it can
[Replying to lots of different people, slightly out-of-order.]
On 12/05/2017 09:52 AM, Eric S. Raymond via devel wrote:
> I'm not clear why we care about the pip cases.
I agree. If this matters, it can always be addressed later.
On 12/05/2017 09:17 AM, Ian Bruene via devel wrote:
> Distro Instal
e...@thyrsus.com said:
> Well, normally it would be a longer freeze, but we're doing this to roll out
> a bug fix on code that has been pretty stable.
Your version of "pretty stable" doesn't match mine.
You want to make a point release to push out a one line patch. You are
dragging along all
devel@ntpsec.org said:
> At least in RPM-land, they like to use the package's own make install when
> possible. I sin't know about Debian packaging.
Thanks.
How do they use it? Do they actually do a "make install" in the build
environment, or somehow capture whatever the install step does?
U
Yo Eric!
On Tue, 5 Dec 2017 23:32:09 -0500
"Eric S. Raymond via devel" wrote:
> Hal Murray :
> >
> > devel@ntpsec.org said:
> > >> Why would we want to do a distro install?
> > > Because it makes life easier for overworked upstream packagers.
> > > By a "distro install" I mean one to rootsp
Hal Murray :
>
> devel@ntpsec.org said:
> >> Why would we want to do a distro install?
> > Because it makes life easier for overworked upstream packagers.
> > By a "distro install" I mean one to rootspace (normally /usr) rather than
> > /usr/local.
>
> How does that help anybody package things u
Yo Hal!
On Tue, 05 Dec 2017 20:15:13 -0800
Hal Murray via devel wrote:
> devel@ntpsec.org said:
> >> Why would we want to do a distro install?
> > Because it makes life easier for overworked upstream packagers.
> > By a "distro install" I mean one to rootspace (normally /usr)
> > rather than /
Ian Bruene via devel :
>
>
> On 12/05/2017 06:47 PM, Eric S. Raymond via devel wrote:
> >I'm OK with this plan - codebase seems to be in pretty good shape -
> >except it might make the cooldown period after Ian lands his
> >install-path fix a little short. Can we hold off three days or so?
>
> I
devel@ntpsec.org said:
>> Why would we want to do a distro install?
> Because it makes life easier for overworked upstream packagers.
> By a "distro install" I mean one to rootspace (normally /usr) rather than
> /usr/local.
How does that help anybody package things up?
Do they have tools that e
Hal Murray :
> >From Subject: Re: Python 3 division
> > My plan is to let the current minor flurry of bug-fixing activity subside
> > and then call a short freeze.
>
> That's what I've been trying to complain about.
>
> If all you do is call a "short" freeze before a release, nobody ever has tim
Hal Murray :
> Why would we want to do a distro install?
Because it makes life easier for overworked upstream packagers.
By a "distro install" I mean one to rootspace (normally /usr) rather
than /usr/local.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the
>From Subject: Re: Python 3 division
> My plan is to let the current minor flurry of bug-fixing activity subside
> and then call a short freeze.
That's what I've been trying to complain about.
If all you do is call a "short" freeze before a release, nobody ever has time
to look around and try t
>> Before or after the point release?
> Before. This is fix that can't do damage and only ensures uniform behavior
> across 2 and 3.
Your imagination needs a tune up. The whole reason this came up was because
an innocent edit like that broke something.
The edit is simple. Verifying that it
> I'm not clear why we care about the pip cases. Our job is to do a user
> install on default prefix (/usr/local), and a distro insrtall on prefix /
> usr. If we can do that, how are we not finished with this problem?
I don't understand the pip case.
Why would we want to do a distro install?
>> If you want to release all the changes since the last release, then we
>> should take the time to do it right.
> I don't necessarily disagree, but do we have testable criteria dor "Do it
> right?"
That should be part of the release process. If it isn't specified there,
then now would be a
On 12/05/2017 06:47 PM, Eric S. Raymond via devel wrote:
I'm OK with this plan - codebase seems to be in pretty good shape -
except it might make the cooldown period after Ian lands his
install-path fix a little short. Can we hold off three days or so?
I have something already. WIP MR
Hal Murray :
> If you want to release all the changes since the last release, then we should
> take the time to do it right.
I don't necessarily disagree, but do we have testable criteria dor "Do it
right?"
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the
Mark Atwood, Project Manager via devel :
> Hi!
>
> Due to our recently done fix for working correctly with the Amazon time
> service, I think it is a good idea to push out a point release this week,
> this coming weekend.
>
> Please make sure that whatever you have pushed to master is ready for
>
Hal Murray :
> > +1. Do it.
>
> Before or after the point release?
Before. This is fix that can't do damage and only ensures uniform
behavior across 2 and 3.
My plan is to let the current minor flurry of bug-fixing activity subside and
then call a short freeze.
--
http://www.c
On 12/05/2017 02:33 PM, Mark Atwood, Project Manager via devel wrote:
Please make sure that whatever you have pushed to master is ready for
release, andor let me know if there is any good reason not to do a
release this weekend.
Only thing I have in master that doesn't match the requirement
> Why would I want to nuke them? Shouldnt I be looking in them, for logs if
> nothing else?
YMMV and such. If it works, I'm generally done with them.
They get out of date. I hate working with out-of-date stuff - too much
opportunity for confusion.
I often grep the whole world to find the us
Yo Hal!
On Tue, 05 Dec 2017 12:35:34 -0800
Hal Murray via devel wrote:
> If you want to release all the changes since the last release, then
> we should take the time to do it right.
+1. Nothing here worth rushing for.
RGDS
GARY
Yo Hal!
On Tue, 05 Dec 2017 12:48:05 -0800
Hal Murray wrote:
> > Well, not exactly true, git status complains about:
> > test-all/
> > test-classic/
> > test-default/
> > test-doc/
> > test-minimal/
> > They should prolly be in .gitignore
>
> I would be happy to add them,
> Well, not exactly true, git status complains about:
> test-all/
> test-classic/
> test-default/
> test-doc/
> test-minimal/
> They should prolly be in .gitignore
I would be happy to add them, but just as happy to leave them out so git
status reminds me to nuke th
Yo Hal!
On Tue, 05 Dec 2017 11:56:15 -0800
Hal Murray wrote:
> > I try my build script first after clone, and option-tester.sh first
> > after clone. I no longer see the issue. Weird...
>
> Can you diff the directories?
Nope, I blew off my old copy. But before I did, git status showed no
> We should plan a point release to ship the fix for interop failure with
> Amazon time service. We're in pretty good shape for one now, but a cople of
> minor issues need to addressed.
I was disappointed in the previous release. It was rushed. We (including
you) were changing things late in
Hi!
Due to our recently done fix for working correctly with the Amazon time
service, I think it is a good idea to push out a point release this week,
this coming weekend.
Please make sure that whatever you have pushed to master is ready for
release, andor let me know if there is any good reason n
> I try my build script first after clone, and option-tester.sh first after
> clone. I no longer see the issue. Weird...
Can you diff the directories?
Another possibility is that ccache got confused.
--
These are my opinions. I hate spam.
___
> +1. Do it.
Before or after the point release?
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Yo Ian!
On Tue, 5 Dec 2017 09:17:51 -0600
Ian Bruene via devel wrote:
> I currently do not have any handle on #417. I know where the issue is
> most likely to be, but do not know how to truly fix the problem short
> of whipping up a completely new build-path-finder (say goodbye to a
> ntpsnmpd
Yo Hal!
On Mon, 04 Dec 2017 20:10:09 -0800
Hal Murray wrote:
> > I get exactly the same results. ???
> > Then my build fails:
>
> Just to make sure...
I'm all ears, this is a weird one, and hopefully related to other
peoples odd issues with DEBUG.
> Any chance you have local edits doing som
Ian Bruene via devel :
>
>
> On 12/05/2017 08:24 AM, Eric S. Raymond via devel wrote:
> >* "Install failure on gentoo Stable" (#417) and "Python site packages
> >installed in wrong location" (#414). Ian has a WIP patch to fix this;
> >it needs to be finished and landed.
>
> I currently do not ha
On 12/05/2017 08:24 AM, Eric S. Raymond via devel wrote:
* "Install failure on gentoo Stable" (#417) and "Python site packages
installed in wrong location" (#414). Ian has a WIP patch to fix this;
it needs to be finished and landed.
I currently do not have any handle on #417. I know where the
Hal Murray via devel :
>
> Several of our python modules don't import division from __future__
> Maybe that's because they don't do any divides. I think it would be simpler
> to always include division so we don't have to remember to see if we need to
> add it every time we a chunk of code that
On Mon, Dec 04, 2017 at 10:38:13PM -0800, Hal Murray via devel wrote:
>
> Subject: ntpsec | Pipeline #14729097 has failed for master | 3c1cc3c8
> From: GitLab
>
> Commit: 3c1cc3c8 ( https://gitlab.com/NTPsec/ntpsec/commit/3c1cc3c8317faa48ce8
> e5b8ef7909c16cb04deab )
> Commit Message: Fix ntpq -
We should plan a point release to ship the fix for interop failure with
Amazon time service. We're in pretty good shape for one now, but a
cople of minor issues need to addressed.
* Packet-received counters not being updated (issue #419). I expect to
fix this later today. Cosmetic issue only.
*
Several of our python modules don't import division from __future__
Maybe that's because they don't do any divides. I think it would be simpler
to always include division so we don't have to remember to see if we need to
add it every time we a chunk of code that does a divide.
[murray@hgm raw]
37 matches
Mail list logo
