Yo Hal!
On Mon, 18 Dec 2017 20:53:25 -0800
Hal Murray via devel wrote:
> Gary said:
> > Well, in Gentoo, you are never supposed to directly
> > access /usr/lib64. You are only supposed to access /usr/lib which
> > is a link to lib32 or lib64, which ever is in current use.
>
> On this Fedora b
Gary said:
> Well, in Gentoo, you are never supposed to directly access /usr/lib64. You
> are only supposed to access /usr/lib which is a link to lib32 or lib64,
> which ever is in current use.
On this Fedora box, /usr/lib/ and /usr/lib64/ are different directories.
/usr/lib64/ is much bigger.
Yo Hal!
On Fri, 08 Dec 2017 17:19:41 -0800
Hal Murray via devel wrote:
> >> We'll need a variation for 32 bit systems.
> > Uh, no. And no. At least not on Gentoo.
>
> Well, in addition to something for 32 bit systems, we may need
> different recipes for different distros.
Uh, not if the
>> We'll need a variation for 32 bit systems.
> Uh, no. And no. At least not on Gentoo.
Well, in addition to something for 32 bit systems, we may need different
recipes for different distros.
Fedora is different than Gentoo. When I cut-pasted Richard's recipe on a 32
bit system, it barfed be
Yo Hal!
Sorry to have helped stir things up, then been offline. Recovering
from the local grunge that is going around my town...
On Fri, 08 Dec 2017 16:09:11 -0800
Hal Murray via devel wrote:
> rlaa...@wiktel.com said:
> > cat > /usr/lib64/python2.7/site-packages/local.pth << EOF
> >> /usr/l
rlaa...@wiktel.com said:
> cat > /usr/lib64/python2.7/site-packages/local.pth << EOF
>> /usr/local/lib64/python2.7/site-packages
>> /usr/local/lib/python2.7/site-packages
>> EOF
> mkdir -p /usr/local/lib64/python2.7/site-packages
> mkdir -p /usr/local/lib/python2.7/site-packages
We'll need a var
> It is closed with, "F27 will have this issue resolved.".
I'm running on F27.
> For existing systems, there are three solutions:
...
rlaa...@wiktel.com said:
> 3) Create a .pth file in the appropriate place, which is somewhere under /
> usr. There are probably existing ones: find /usr/lib*/pyth
I agree that your system does not have /usr/local in its sys.path by
default.
I think that's broken.
Here's the relevant RedHat bug:
https://bugzilla.redhat.com/show_bug.cgi?id=662034
It is closed with, "F27 will have this issue resolved.".
For existing systems, there are three solutions:
[murray@hgm raw]$ ls /usr/local/lib/python2.7/site-packages
[murray@hgm raw]$ ls /usr/local/lib64/python2.7/site-packages
ls: cannot access '/usr/local/lib64/python2.7/site-packages': No such file or
directory
[murray@hgm raw]$
[murray@hgm raw]$ sudo mkdir -p /usr/local/lib/python2.7/site-package
On 12/08/2017 12:44 PM, Hal Murray wrote:
>
>> What is your full sys.path?
>> $ python -c 'import sys; print sys.path'
>
> [murray@hgm raw]$ printenv PYTHONPATH
> /usr/local/lib/python2.7/site-packages
> [murray@hgm raw]$ python -c 'import sys; print sys.path'
> ['', '/usr/local/lib/python2.7/s
On 12/07/2017 03:06 PM, Fred Wright via devel wrote:
> The underlying problem is essentially that
> there's no equivalent of ld.so.conf for Python
You can add paths (one per line) in a .pth file in:
/usr/lib/python${ver}/${x}-packages
where $x is normally "site", but "dist" on Debian.
--
Richar
> What is your full sys.path?
> $ python -c 'import sys; print sys.path'
[murray@hgm raw]$ printenv PYTHONPATH
/usr/local/lib/python2.7/site-packages
[murray@hgm raw]$ python -c 'import sys; print sys.path'
['', '/usr/local/lib/python2.7/site-packages', '/usr/lib/python27.zip',
'/usr/lib64/pyt
On 12/08/2017 02:20 AM, Hal Murray wrote:
>> Does the /usr/local/lib/python... directory exist?
> Yes.
What is your full sys.path?
$ python -c 'import sys; print sys.path'
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mail
On 12/08/2017 02:20 AM, Hal Murray wrote:
> I haven't done a lot of testing. waf install --destdir=foo didn't crash like
> it would if it tried to write to /usr/ and the printout all looked good.
Since I know destdir worked for me in the package build, I looked into
this again to figure out what
devel@ntpsec.org said:
> It works for me when building the Debian package, but I'm otherwise having
> trouble with it. I haven't done a lot of testing, but it seems to be the
> case that it is still trying to install the Python bits directly to /usr,
> ignoring the destdir.
I haven't done a lot
On 12/08/2017 01:48 AM, Hal Murray via devel wrote:
> Richard Laager said:
>> NTPsec's `waf configure --destdir` seems broken. That should be fixed,
>> especially if helping packagers is a priority.
>
> --destdir work on install rather than configure.
> --prefix works on configure not install
It
Richard Laager said:
> NTPsec's `waf configure --destdir` seems broken. That should be fixed,
> especially if helping packagers is a priority.
--destdir work on install rather than configure.
--prefix works on configure not install
That doesn't seem obvious to me, but that stuff is probably abo
On 12/07/2017 10:59 PM, Gary E. Miller wrote:
>> The default case is prefix=/usr/local, which (correct me if I'm wrong)
>> works without hacks.
>
> Sadly, recently broken.
NTPsec has wafhelpers/fix_python_config.py, which is the hack in question.
Have you tried the patch I posted to #414, which
> And worse, SOME of my install goes in /usr, some in /usr/local. It should
> be all one, or all the other.
./waf configure --prefix=foo
says
PREFIX: /home/murray/ntpsec/raw/foo
After ./waf build, ./waf install says:
WafError: Could not install the file
'/usr/lib/p
Yo Richard!
Uh, sorry, I've been offline with the grunge.
On Thu, 7 Dec 2017 20:22:48 -0600
Richard Laager via devel wrote:
> On 12/07/2017 03:06 PM, Fred Wright via devel wrote:
> > On Wed, 6 Dec 2017, Ian Bruene via devel wrote:
> >
> >> For installs the only remaining problem is that for
On 12/07/2017 03:06 PM, Fred Wright via devel wrote:
> On Wed, 6 Dec 2017, Ian Bruene via devel wrote:
>
>> For installs the only remaining problem is that for unknown reasons it
>> sometimes doesn't follow the PREFIX when installing the python libs.
>
> There's nothing "unknown" about it.
Actua
On Wed, 6 Dec 2017, Ian Bruene via devel wrote:
> For installs the only remaining problem is that for unknown reasons it
> sometimes doesn't follow the PREFIX when installing the python libs.
There's nothing "unknown" about it. This has been discussed at length on
this ML, as well as being expl
> The canonical way of packaging for system install is to use PREFIX=/usr and
> then do
> make DESTDIR=/some/staging/directory install
Thanks.
Looks like waf has a --destdir option that works with the install command
and --prefix that works with configure.
--
These are my opinions. I hate
Hal Murray :
>
> > I'd prefer to go to an accelerated 1.1
> > The main reason is that there isn't just one ntpq fix. ...
>
> "accelerated" is ambiguous. Do you mean release sooner than previously
> planned or reduced time between now/freeze and release bits being available?
The former.
> I
> I'd prefer to go to an accelerated 1.1
> The main reason is that there isn't just one ntpq fix. ...
"accelerated" is ambiguous. Do you mean release sooner than previously
planned or reduced time between now/freeze and release bits being available?
I'd be happy to release now rather than J
> If you're going to say "identify your customers: the plan has to specify how
> we can do that.
There is a large part of project management that depends upon the skill and
experience of the project manager. You won't get a crisp specification for
those areas.
The obvious example is "How long
Hal Murray :
> > Remember, Linux used to have stable-branch releases. It no longer does
> > because Linus noticed the same failure mode I did. When you start
> > cherry-picking onto a "safe" branch you increase the expected time to
> > discovery of any bugs on your unstable branch. This is not a
devel@ntpsec.org said:
> Remember, Linux used to have stable-branch releases. It no longer does
> because Linus noticed the same failure mode I did. When you start
> cherry-picking onto a "safe" branch you increase the expected time to
> discovery of any bugs on your unstable branch. This is no
Achim Gratz via devel :
> Eric S. Raymond via devel writes:
> > I'd prefer to go to an accelerated 1.1
>
> So what exactly do you mean by "accelerated"?
We were vaguely planning on 1.1 in January.
--
http://www.catb.org/~esr/";>Eric S. Raymond
My work is funded by the Internet
Matthew Selsky via devel :
> OK, then let's put those several fixes on a branch from the 1.0 tag and
> release from there (if we're looking for a quick release).
>
> There's been too much churn in non-PLL code removal, waf changes for
> python install paths, etc, to mix chose changes with actual
Eric S. Raymond via devel writes:
> I'd prefer to go to an accelerated 1.1
So what exactly do you mean by "accelerated"?
> The main reason is that there isn't just one ntpq fix. There have been a
> whole bunch of small but user-visible and irritating bugs in ntpq
> reporting since 1.0 - we had
On Wed, Dec 06, 2017 at 12:14:18PM -0500, Eric S. Raymond wrote:
> Matthew Selsky via devel :
> > On Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote:
> > >
> > > If you want to do a quick release, then we should backport critical
> > > fixes. I
> > > assume that turns into a b
Hal Murray via devel writes:
> How do they use it? Do they actually do a "make install" in the build
> environment, or somehow capture whatever the install step does?
The canonical way of packaging for system install is to use PREFIX=/usr
and then do
make DESTDIR=/some/staging/directory install
Matthew Selsky via devel :
> On Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote:
> >
> > If you want to do a quick release, then we should backport critical fixes.
> > I
> > assume that turns into a branch in git.
>
> Amen. We should release 1.0.1 that just includes the ntpq
On 12/06/2017 09:11 AM, Richard Laager via devel wrote:
Probably? The behavior was already correct for the distro package. Was
anything else broken?
For installs the only remaining problem is that for unknown reasons it
sometimes doesn't follow the PREFIX when installing the python libs.
-
On 12/06/2017 12:36 AM, Gary E. Miller wrote:
> On Tue, 5 Dec 2017 23:57:37 -0600
> Richard Laager via devel wrote:
>> 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 Tue, Dec 05, 2017 at 12:35:34PM -0800, Hal Murray via devel wrote:
>
> If you want to do a quick release, then we should backport critical fixes. I
> assume that turns into a branch in git.
Amen. We should release 1.0.1 that just includes the ntpq fix and the AWS fix
(and any other critica
On 12/05/2017 11:57 PM, Richard Laager via devel wrote:
From my reading of that wiki page, the distro-packaged Python uses
dist-packages whenever stock Python would use site-packages. This way,
if you install the distro Python package *and* Python from source, you
can install modules for each
Richard Laager via devel :
> On 12/05/2017 10:32 PM, Eric S. Raymond via devel wrote:
> > At least in RPM-land, they like to use the package's own make install
> > when possible. I sin't know about Debian packaging.
>
> Yes, it's ideal to use upstream's make install. Obviously, we packagers
> can
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
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 /
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 :
> 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
> 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
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
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
> 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
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
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
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.
*
56 matches
Mail list logo
